Während die Migration per Autoupdate und auch manuell noch läuft, erste Informationen zum Neuen Netz.
Neuer Kartenserver
Die migrierten Knoten sind nicht mehr auf der bisherigen Karte zu betrachten, sie werden dort als offline angezeigt. Dies hat technische Hintergründe, die Informationen werden von den aktualisierten Knoten auf andere Weise im Netz propagiert. (Technisch: statt über A.L.F.R.E.D werden die Informationen nun über einen Gluon-eigenen Dienst, respondd, verteilt.)
Die Adresse des neuen Mapservers lautet https://map03.4830.org/map_Freifunk%20Bielefeld/ — die alte Adresse lautet(e) https://map.freifunk-bielefeld.de/meshviewer/.
Aufgrund unterschiedlicher Techniken der Statistikserver gehen leider die Infomationen über die bisherige Netzzugehörigkeit verloren, sodaß auf der neuen Karte alle Knoten als erst Ende Februar/Anfang März ins Netz gekommen angezeigt werden.
Netzzugehörigkeit
Das bisherige Freifunk-Bielefeld-Netz ersteckte sich von Bielefeld im Südwesten bis nach Hannover und Hildesheim — und zwar als eine Layer-2-Wolke, mit einem auf dem Knoten konfigurierbaren Community-Feld.
In den Vorplanungen war uns – Akteuren aus den Freifunk-Gruppen aus Lippe und dem Kreis GT – relativ schnell klar, daß wir die relevanten Knotengruppen – Bielefeld und Bad Oeynhausen – in separate Netze überführen möchten, so, wie wir dies auch schon in den anderen von uns betreuten Gegengen tun.
Aus $Gründen gibt es in der Migrationsfirmware auch eine Abgrenzung für Minden — aber egal ob »BFE«, »BOY« oder »MID« ausgewählt wird, aktuell landen, nach wie vor, alle diese Knoten und ihre Clients in einem Layer-2-Netz.
Die Migrationsfirmware nutzt, wo möglich, einen bestehenden Internetzugang per WAN-Port, um servergestützt aus ggf. eingetragenen Koordinaten eine Netzzugehörigkeit zu ermitteln. In den Städten Bielefeld, Bad Oeynhausen und Minden werden die FFBI-Knoten entsprechend den Netzen »BFE«, »BOY« oder »MID« zugewiesen — wie aber schon beim manuellen Update einigen Knotenbetreibern aufgefallen ist: ergibt die Geokoordinate keinen Punkt in den genannten Städten – wir nutzten für dieses »Reverse Geocoding« eine eigene OpenStreetMap-Nominatim-Instanz –, wird der Knoten dem 4830.org-»Out-of-Area«-Netz, »zzz«, zugeschlagen. Dies ändert dann zwangsläufig die ausgestrahlte SSID — aber dies nimmt letztlich nur den nächsten Schritt vorweg: die Aufteilung in dedizierte Stadtnetze, die dann auch schmerzfrei wachsen können.
Performance
Das Neue Netz setzt statt auf fastd- auf L2TP-VPN-Tunnel — auch so ein lessons-learned-Ding der letzten X Jahre. fastd verbrät (in Relation zur CPU-Leistung) extrem viel CPU-Zeit auf dem Knoten, aber *auch* auf den Gateways — um Daten, die schon vor Ort unverschlüsselt in der Luft waren und gleich wieder unverschlüsselt ins Internet gehen, zwischendrin abzusichern. In westlichen Demokratien, die gerade Netzbetreibern untersagen, in den übertragenen Datenverkehr zu spiecken, ist unserer Ansicht nach die Verkapselung des Datenverkehrs in L2TP-Frames Hinweis genug an den Transporteur, seine Nase raus zu halten.
Und dadurch alleine erreichen wir, zumindest auf der zehn Jahre alten Plattform der 841er, schon einen Durchsatzboost von 10 auf 40 MBit/sec.
Weitere Abweichungen?
Vermutlich sind uns bei dem komplexen Vorgehen Dinge durchs Raster gefallen oder schlicht übersehen worden: bitte sprecht mit uns, damit wir hier nachjustieren können.
Nachtrag: Config-Mode
Eine gehäufte Nachfrage gab es zum sog. »Config-Mode«, also dem speziellen Betriebsmodus in der Gluon-basierten neuen Freifunk-Firmware. Trotz entsprechender Verlinkung in mindestens einem anderen Beitrag, scheinen Details untergegangen zu sein, daher hier eine ausführlichere Betrachtung:
Generell gibt es bei Gluon-basierten Firmwares gibt zwei Betriebsmodi: den Freifunk-Modus und den Konfigurations-Modus, üblicherweise »Config-Mode« (oder auch »Setup-Mode«) genannt.
Normalerweise funkt ein einmal konfigurierter Freifunk-Knoten (siehe unten zum Ablauf der Firmware-Migration) mit einer Gluon-basierten Firmware im Freifunk-Modus, nimmt über Funk und/oder VPN am Freifunk-Mesh teil und versorgt (sofern nicht anders konfiguriert) Endgeräte per WLAN und ggf. kabelgebundene Geräte über etwaige LAN-Ports. Komplexere Setups können über »Mesh-on-LAN« oder auch »Mesh-on-WAN« realisiert werden — »Mesh-on-WAN« gab‘ es bei der alten FFBI-Firmware auch, aber dies, wie auch spezielle LAN-Port-Zuordnungen, wurden bei der Migration nicht übernommen, da nicht in jedem Fall 1:1 abbildbar.
In der FFBI-Firmware war der Knoten über’s LAN unter 192.168.133.1 per SSH & HTTPS zur Konfiguration passwortgeschützt erreichbar. Bei Gluon-basierten Firmwares hingegen ist dies, wie gesagt, ein anderer Betriebsmodus, besagter Config-Mode. Hier sind viele Dinge konfigurierbar (»Mesh-on-LAN«, »Mesh-on-WAN«, »Nachtruhe« (Abschaltung der Versorgung von Endgeräten per WLAN zwischen 22 und 6 Uhr), Geokoordinaten, Kontaktadressem …), feste IP-Adresse auf dem WAN-Port, feste WAN-DNS-Server, …) — aber eben nur in einem andereren Betriebsmodus, in dem u. a. WLAN und VPN abgeschaltet sind. Um in diesen Modus zu gelangen, ist am Knoten physisch die Reset-Taste so lange zu drücken, bis der Knoten neu startet — dieser Neustart geschieht dann im Config-Modus. (Alternativ ist auch per Kommandozeile ein solcher Reboot in den Config-Mode möglich: per SSH-Login (das Knoten-Passwort wurde aus der FFBI-Firmware übernommen) über die öffentliche IPv6-Adresse – oder die Adresse des WAN-Ports im LAN – auf den Knoten gehen und dort dann »uci set gluon-setup-mode.@setup_mode[0].enabled=’1′ && uci commit gluon-setup-mode && reboot« eingeben.)
Ab hier trennen sich nun die Zugangswege in »Standard-Gluon« und »Gluon-4830«. Standard-Gluon setzt auf dem LAN statisch die IP-Adresse 192.168.1.1/24, darüber wäre denn der Config-Mode per SSH (root, passwortlos) und HTTP erreichbar, fertig. Für installierte Freifunk-Knoten, die per WAN per VPN teilnehmen, heißt dies: hinlaufen, Kabel von WAN auf LAN umstecken, konfigurieren und neu starten, hinlaufen, Kabel von LAN auf WAN umstecken. Ähnlich sieht es bei der Erstinstallation aus: ein zweites (oder auf modernen Laptops: erstes) LAN-Interface auf Väterchens Laptop ist nicht trivial. Und unnötige Eingriffe in fremde Windows-Installationen kann und will kein Freifunker verantworten. Daher hat sich die Gütersloher Freifunk-Initiative schon um 2015 entschieden, einen anderen Weg zu gehen.
Bei Gluon-4830 hat der Knoten im Config-Mode weiterhin über WAN eine Verbindung — allerdings, durch Gluon-Eigenarten bedingt, hat der Knoten eine andere WAN-Hardware-Adresse (MAC-Adresse) im Config-Mode als im Freifunk-Mode., was typischerweise eine andere lokale IP-Adresse bedingt. Um den Zugriff zu erleichtern – vergebene IP-Adressen per DHCP sind nicht immer leicht zu ermitteln –, meldet sich ein Gluon-4830-Knoten beim 4830-Setup-Server an. Wenn der Nutzer also https://setup.4830.org aufruft, und der Knoten aus dem gleichen (privaten) IPv4-Netz sich bei setup.4830.org meldet, kann die Webseite einen Redirect machen, sodaß der Nutzer unkompliziert auf die Konfigurationsoberfläche des Knotens im Config-Mode geleitet werden kann.
Langer Rede kurzer Sinn: bei einer 4830-Firmware einfach aus dem lokalen Netz setup.4830.org aufrufen, die Technik im Hintergrund arbeitet für Dich und nach wenigen Minuten landest Du i. d. R. auf der Konfigurationsoberfläche deines Freifunk-Knotens.
Für komplexere Setups, wo über LAN zugegriffen werden muß, hat ein 4830-Knoten im Config-Mode die statische IP-Adresse 203.0.113.1/24 (/24 heißt Netzmaske 255.255.255.0) — mit allen Vor- und Nachteilen.
Ein 4830-Knoten im Config-Mode wird nach spätestens einer Stunde im Config-Mode allerdings auch neu starten, um einem versehentlichen Aufruf des Config-Modes vorzubeugen/diesen zu kompensieren.
Spezialfall »Migration FFBI- auf 4830-Firmware«: beim Autoupdate der FFBI-Firmware startet eine Gluon-basierte Firmware ohne vorhandene Konfiguration; in der Folge geht die Gluon-Firmware in den Config-Mode. Weitergehende Skripte verändern nun, basierend auf der FFBI-Konfiguration, die Gluon-Einstellungen und erzwingen einen Neustart. Dabei wird allerdings auch der (Gluon-) Status »Knoten konfiguriert« gesetzt — anders ist eine automatisierte Firmware-Migration nicht lösbar … Sollte das lokale Ergebnis nicht funktional sein, bleibt an sich nur der händische Aufruf den Config-Modes.