Orginaler Blog-Post: Migration abgeschlossen – Freifunk Kreis GT
Seit dem 5. Juli 2024 nutzen Freifunk Celle, Freifunk Gifhorn, Freifunk Uelzen und Freifunk Wendland die Firmware und Infrastruktur des 4830.org e. V.
Geschafft. Nach längerer Vorarbeit erst auf informell-privater, schlußendlich dann auf Vereinebene, ist die Migration der Knoten des Freifunk Uelzen e. V. – der für die Infrastruktur der Knoten in den niedersächsischen Landkreisen Celle, Gifhorn, Uelzen sowie dem Wendland verantwortlich zeichnet — auf die Infrastruktur des 4830.org e. V. – der schon für Communities in MeckPomm, NRW und Niedersachsen das ›Netzbackend‹ bereitstellt – in unter 24 Stunden umgesetzt worden.
Bedingt durch die Ausgangslage – ›Batman v14‹ und Gluon v2017/2018 — wurde ein zweistufiges Verfahren angewendet — Updates sind nicht von jeder auf jede Gluon-basierte Firmware möglich …
- Update von der FFUE-FW auf eine 4830.org-FW auf Basis Gluon v2019.1.3 — hier findet die Konfigurationsänderung von »multiple Firmwares, one Mesh« auf »single Firmware, multiple Meshes« statt
- Von der Migrationsfirmware Update auf aktuelle 4830.org-Gluon-v2021-Firmware
Aus dem Stand steht dann auch den Knotenbetreibern im Einzugsbereich des Freifunk Uelzen e. V. wieder aktuell kaufbare Hardware via der Hardwareempfehlung des 4830.org bereit.
Ein weiterer Vorteil: Zugänge des Freifunk Uelzen sind nach dem Update i. d. R. leistungsfähiger als zuvor, da das neue VPN-Protokoll ›L2TP‹ deutlich ressourcenschonender arbeitet als das bisherige ›fastd‹-Protokoll.
Aber wo Licht ist … Beim Umzug von knapp 800 Knoten inklusive des Wechsels des Meshprotokolls bleiben leider auch einige wenige auf der Strecke.
Das Updatemuster ist »chaotisch«, wer das Update ziehen kann, tut es. Dieses ist in Mesh-Ketten ein Problem, denn sobald ›weiter vorne‹ (gen Internetzugang) das Meshprotokoll sich ändert, sind alle ›hinteren‹ Knoten erst einmal abgehängt.
Die Firmware versucht, dies selbsttätig zu kompensieren, und zwar erkennt sie einen mehrstündigen Ausfall der Verbindung ins Mesh als Fehler und versucht dann, offene Freifunk-Knoten in der Umgebung zu finden. Angemeldet als klassischer WLAN-Client versucht die Firmware dann, über diese Verbindung ein Firmwareupdate zu installieren. In der Regel behebt dieser Ansatz ungünstiges Timing beim Firmwareupdate — aber leider nicht immer: wo z. B. bei größeren Entfernungen auf Mesh-on-LAN gesetzt wird, kann dieses Procedere ins Leere laufen, ohne offenes Freifunk-WLAN drumherum bleibt das System statisch.
Letzten Endes haben wir (auch) bei dieser Migration über 95% der Knoten ›einfach so‹ von einem zehn Jahre alten Meshprotokoll und ca. halbsoalter Firmware wegmigriert, dabei sind Nacharbeiten bei rd. 5 von 23 ER-X-Knoten notwendig geworden – weit weniger als befürchtet – und bei grob einer Handvoll anderer Installationen sind händische Eingriffe wohl unvermeidlich.
Bei den ER-X war es ein Lottospiel, wieviele der 23 eingesetzten EdgeRouter X haben Probleme im Flash, die eine manuelle Nachbehandlung erfordern? Bei anderen Installationen war nur bekannt, daß das quasi zufällige Updating zu Problemen führen kann, welche aber durch den Autoupdate-als-Client-Modus meistens aufgefangen werden sollten.
In einer idealen Welt würde man vorab Abhängigkeiten ermiteln und daraufhin selektives Updating auf dem Firmwareserver umsetzen — das übersteigt dann aber auch die Möglichkeiten eines von Hobbyisten getragenen Projektes. Und auch in der Realität findet man solche Detailtiefe eher selten: kommerzielle Anbieter schätzen vor einem Update die Ausfallrate und besetzen bestenfalls die Callcenter entsprechend; Ausfälle sind halt Teil der Realität und mit ihnen ist einfach umzugehen.
Daher – bei den von Nacharbeit Betroffenen mag man das nicht so sehen, und dafür haben wir vollstes Verständnis – knallen ehrlicherweise in Uelzen und Gütersloh an diesem Wochenende die Sektkorken ob einer ganz überwiegend gut abgelaufenen Migration.
