Am 29.07.17 fand im Herzen von Gera die 3. Aprestour statt. Gemeinsam mit dem Veranstalter haben wir hierbei Freifunk für diesen Tag aufgebaut. Hierzu standen uns 7 Knoten zur Verfügung. Zwei Knoten befanden sich an der Videowand und zwei Nanostation am Zugangspunkt zum Internet mit einer Bandbreite von 25 MBit, welcher von einen Bürger dankenswerterweise zur Verfügung gestellt wurde. Somit konnte die Veranstaltung abgesichert werden. Ein weiterer Knoten befand sich an unseren Freifunk Infostand.
Zu Spitzenzeiten waren 145 Clients im Freifunk Netz eingeloggt.
Ich möchte mich hiermit bei dem Veranstalter Lucas Schädlich für die gute Zusammenarbeit bedanken. Weiterhin sage ich ein großes Dankeschön an alle Freifunker, welche aktiv diese Veranstaltung abgesichert haben. Wir konnten hierdurch unserer Können abermals unter Beweis stellen.
- Details
- Geschrieben von: Lutz
- Kategorie: Aktuelles
CC BY-SA 2.5 by Arpad Horvath |
Basierend auf dem gerade erschienenen GLUON v2016.2 erstellen wir derzeit eine neue Beta-Version der Router-Firmware für unsere Community Gera-Greiz, die Version 0.8.9-beta1. Diese sollte ab heute (22.9.2016) abend zum Download und fürs Autoupdate zur Verfügung stehen. Sollten damit keine Probleme auftreten, wird kurzfristig eine statile Version nachgeschoben, welche dann auf dieser Beta-Version basiert.
Seit der aktuellen stabilen Version 0.8.8 gibt es folgende Neuerungen:
- Unterstützung für viele neue Routermodelle, vor allem solche mit ath10k WLAN Chipsatz, hinzugefügt. Z.B. auch:
- GL-AR150
- Archer C5 v1, Archer C7 v2
- TL-WR842N/ND v3
- UniFi AP AC Lite und Pro
- RaspberryPi 1 und 2
- Die Modellnamen vieler Ubiquiti-Router werden jetzt eindeutig erkannt. Damit wird z.B. eine Loco jetzt als Loco angezeigt und nicht mehr als Bullet.
- Aktivierung des Parameters "mesh_no_rebroadcast" für Mesh-on-WAN/LAN Interfaces. Das soll einiges an Traffic einsparen.
- neue UCI-Option "gluon-core.@wireless[0].preserve_channels": Wird diese auf "1" gesetzt, werden manuell geänderte Kanäle euf einem Router bei einem Update nicht mehr überschrieben
- In den Advaced Settings des Config-Modes kann nun für Nanostations und CPE 210/510 PoE Passthrough konfiguriert werden
- Das Feld zur Angabe der Höhe im Config-Mode kann ausgeblendet werden. Das haben wir in unserer Firmware auch getan.
- Die Angabe eines Kontaktes im Config-Mode kann jetzt verlangt werden. Auch das ist in unserer Firmware jetzt aktiviert.
- Der Knotenname kann jetzt beliebige Sonderzeichen enthalten.
- Beim 2,4GHz-WLAN können jetzt die unterstützten Raten gesetzt werden. Das ist bei uns nun so eingeschränkt, daß 802.11b-Clients nicht mehr unterstützt werden. Dafür sollte die Performance steigen.
- Die Stabilität der WLAN-Treiber soll entscheidend verbessert worden sein.
- Ab sofort verzichten wir auf das automatische Eintragen von SSH-Schlüsseln unserer Admins auf den Routern. Dies hatte es zwar ermöglicht, in den verschiedensten Notfällen schnell eingreifen zu können. Wer dies nicht wünschte, konnte den Schlüssel z.B. im Config-Mode löschen. Leider wurde der Schlüssel bei jedem Update automatisch wieder eingetragen. Das ist verständlicherweise für alle, die eine Zugriffsmöglichkeit auf ihre Router explizit nicht wünschen, nicht akzeptabel. Deswegen wird nun generell kein Schlüssel mehr gesetzt. Wer dennoch nicht auf die sehr sinnvolle Möglichkeit des Supports durch unsere Admins verzichten möchte, muß deren SSH-Schlüssel nun während der Konfiguration von Hand selbst eintragen.
- Details
- Geschrieben von: Jörg
- Kategorie: Aktuelles
CC BY-SA 2.5 by Arpad Horvath |
Basierend auf GLUON v2016.2.6 steht ab sofort die neue stabile Firmware 0.8.18 für die Community Gera-Greiz zur Verfügung. Bei Knoten mit aktiviertem Autoupdater erfolgt die Verteilung automatisch in den kommenden 2 Wochen. Seit der vorangegangenen stabilen Version 0.8.16 hat sich nicht allzu viel geändert:
- Unterstützung für TP-Link TL-WR841N/ND v12
- Behebung kleinerer Fehler und eines für uns unbedeutenden Sicherheitsloches
- Behebung eines Fehlers bei Upgrades von x86-basierenden Knoten
Der letzte Punkt ist wichtig für alle, die Knoten auf PC-Hardware (Intel/AMD) betreiben. Wird beim Upgrade auf eine der nächsten Firmware-Versionen diese Version 0.8.18 ausgelassen, geht die gesamte Konfiguration des Knotens verloren. Er würde sich also nicht mehr mit Gateways und anderen Knoten verbinden und müßte vor Ort neu konfiguriert werden.
Die Version 0.8.18 wird voraussichtlich die letzte sein, welche auf dem nicht mehr gepflegten OpenWRT aufbaut. Die nächste Version läuft dann mit GLUON v2017.x unter dem aktuellen, modernisiertem LEDE. Wahrscheinlich werden wir dabei auch den Schritt von Fastd zu TunnelDigger/L2TP vornehmen. Beides sind VPN-Protokolle, welche für nicht (nur) per Mesh angebundene Knoten über unsere Gateways die Verbindung zum restlichen Netz unserer Community aufnehmen. TunnelDigger/L2TP ist im Vergleich zu Fastd ressourcenschonender und schneller, so daß auch weniger leistungsstarke Knoten die volle Kapazität des Internet-Anschlusses ausschöpfen können.
Auf Grund dieser recht wesentlichen Änderungen sind vor diesem Update noch umfangreiche Tests geplant. Unsere derzeitige experimentelle Firmware basiert bereits auf GLUON v2017.1 und LEDE und verwendet nur noch TunnelDigger/L2TP. Diese läuft auf ca. 25 Knoten bisher recht gut. Als nächsten Schritt werden wir beim kommenden Techniktreffen auf dieser Basis eine neue Beta-Version erstellen. Damit können wir auf allen Beta-Knoten testen, ob beim Wechsel auf die neue Firmware Probleme auftreten. Für eine breitere Testbasis wünschen wir uns, daß sich noch mehr Knotenbetreiber an den Betatests beteiligen. Auch Nutzer der aktuellen experimentellen Firmware sollten nach Möglichkeit nochmal den Schritt von der derzeitigen stabilen auf die folgende Beta-Firmware durchspielen. Wie das genau geschehen kann, erklären wir, sobald die neue Beta-Firmware zur Verfügung steht.
- Details
- Geschrieben von: Jörg
- Kategorie: Aktuelles
Unsere Community nutzte für die internen Absprachen anfangs Telegram. Später wechselten wir relativ geschlossen auf Riot/Matrix (https://matrix.ffggrz.de), um unsere Daten nicht in fremde Hände geben zu müssen.
Nach einigen Missverständnissen in der internen Kommunikation, gingen wir dazu über, die relevanten Räume im Matrix-Raumverzeichnis zu veröffentlichen und die Räume insgesamt (einladungsfrei) zu öffnen.
Durch unsere Bekanntschaften bei den benachbarten Communities besuchten gelegentlich auch deren Mitglieder unsere Räume und tauschten sich mit uns aus, so wie wir bei den Nachbarn vorbeischauten.
Ein Mitglied (unser "Troll") fiel dabei durch sein hohes Schreibvolumen und die Inhaltsleere seiner Monologe auf und machte in unserem Standardraum eine vernünftige Diskussion der restlichen Mitglieder unmöglich.
Matrix-interne Ansätze (benutzerspezifisches Verbergen (ich sehe seine Beiträge nicht) und Blockieren (nur bei verschlüsselten Räumen, er kann meine Beiträge nicht lesen)) führten zu nichts, da die gelegentlichen Antworten einzelner (nicht-verbergender) Mitglieder zu Konfusion führten.
Der Raum wurde unbenutzbar. Wir eröffneten einen neuen "Haupt"-Raum, benannten den alten um und ließen den Troll zurück.
Das ging relativ lang gut, da er sich im Restraum austoben konnte und noch einzelne, resistente Mitglieder da waren, die ihn lasen. Er bekam seinen Fisch und der Hauptteil von uns seine Ruhe.
Gestern kaperte er den Hauptraum und jetzt steht abermals die Frage an, wie wir damit umgehen.
Nachdem seine Beleidigungen ("[A] ist echt wie der Köter vom [B]") nach einer klaren Verwarnung ("Du hast unseren letzten Raum mit deinen Monologen unnutzbar gemacht und startest hier dasselbe. Es kann nicht angehen, dass du unser friedliches Miteinander derart störst und eine ernstgemeinte Diskussion unmöglich machst. Hier ist jetzt Schluss.") überhand nahmen, habe ich ihn zweifach des Raumes verwiesen und nach jeweiliger anschließender Rückkehr endgültig gebannt. Auf seinem bis dato gleichzeitig genutzten Zweitkonto machte er einfach weiter, so dass ich das auch bannte.
Ruhe kehrte ein.
Für 10 Minuten.
Währenddessen richtete er ein neues Konto ein und machte an gleicher Stelle weiter. Erneuter Bann.
Das Spiel wiederholte sich ein paar Mal, bis ich schließlich den Raum schloss (Eintritt nur noch auf Einladung).
Daraufhin betrat er einen anderen (unseren Witze-Raum) und machte dort weiter. Thematisch unpassend, beleidigend und störend.
Wir halten die dynamischen Sperrungen personell nicht durch. Freifunk ist für uns alle ein Hobby, dem wir abends nachgehen. Wir haben nicht das Zeitkontingent, nicht die Lust und auch nicht die Motivation, um mit jemandem mitzuhalten, der den ganzen Tag frei hat und jeden Gedanken/jede Beleidigung in den Raum stellt.
Die Zeit, die wir hier verlieren, fehlt an anderer Stelle.
Einige von euch mögen das vielleicht lustig finden.
Für uns stellt es ein großes Ärgernis dar, wenn vernünftige Diskussionen und Absprachen unmöglich werden, wenn man erst seitenweise Text scrollen muss um die wichtigen Inhalte zu finden.
Das Schließen der Räume kann nur ein vorübergehendes Mittel sein, bis sein größter Schwung verflogen ist. Allerdings warte ich darauf schon seit 2-3 Jahren ohne Erfolg.
Ignorieren/Blockieren/Kicken/Bannen half nicht, einen Umzug will ich nicht schon wieder, denn irgendwann muss auch mal Schluss sein. Den gesunden Menschenverstand, auf den ich gern setzen würde, kann ich hier leider nicht mehr unterstellen. Hier geht es ausschließlich um Störung unserer Community, während uns gleichzeitig vom Troll vorgeworfen wird, dass wir nicht frei, offen und freifunkig genug sind. Das unterstellte Nazi-Gedankengut, die AfD-Nähe/Mitgliedschaft/Arschkriecherei (bei den Wahlen 2019 holten sie 30% im Stadtrat und für Europa) ist für mich und seine anderen adressierten Ziele beleidigend, aber (vermutlich) nicht justiziabel.
Wie geht man damit um, wenn einem ein Teil des Hobbies (freie Netze) durch einen Ideologen kaputt gemacht wird, der freie Netze fordert und durch sein Vorgehen ebendiese freien Netze stört?
Was tut man, wenn die Gegenseite nur auf (Zer)Störung aus ist?
- Details
- Geschrieben von: Matthias Drobny
- Kategorie: Aktuelles
Dieser Artikel zeigt exemplarisch den Aufbau zur Bandbreitenmessung einer Richtfunkstrecke.
Folgende Hardware und Software kam dabei zum Einsatz:
- 2x Ubiquiti NanoBeam AC* (Gluon Firmware 0.82)
- 1x APU von PC Engines (Gentoo Linux, Installation mit fastd usw.)
- 1x Ubiquiti TS-8-PRO Switch*
- 1x TP-Link TL-WR1043ND* (Gluon Firmware 0.82)
- 1x HP Compaq DC7700 Convertible Minitower (Gluon Firmware 0.82)
- 2x Laptops als Messpunkte (Linux, iperf zur Messung)
Der vollständige Artikel ist im Wiki verfügbar.
- Details
- Geschrieben von: Matthias Drobny
- Kategorie: Aktuelles