Netzmodernisierung: neues Meshprotokoll

Orginaler Blog-Post: https://freifunk-kreisgt.de/netzmodernisierung-neues-meshprotokoll/

Unser Netz hat leider technologisch ein wenig Staub angesetzt, aber mittlerweile haben wir die tech­nischen Hebel in Stell­ung ge­bracht, lange über­fällige Änder­ungen um­zu­setzen.

Nachdem Firmware 1.0.0 nun ausgerollt ist – wer das automatische Update deaktiviert hat, möge bitte schnellstens manuell updaten! –, stehen drei grundlegenden Änderung an der Netzinfrastruktur an. Dies betrifft neben Freifunk im Kreis GT auch die Müritz-Region und die Feldberger Seenlandschaft!

An sich sollte es erst auf dem nächsten Treffen in Gütersloh besprochen werden, welche Änderung welche Priorität genießen solle, aber ein zufälliges Zeitfenster beschleunigte die Dinge nun.

Als Test für den gravierenden Wechsel von B.A.T.M.A.N. Advanced, »compatibility mode« v14, auf v15 – die eben nicht untereinander kompatibel sind, d. h. ein Knoten mit v14 und ein Knoten mit v15 reden zwar lautstark aufeinander ein, da der eine aber nur holländisch und der andere nur französich spricht und versteht, kommt keine Kommunikation zustande – findet derzeit ein Wechsel des Mesh-Protokolls statt: von IBSS geht es auf 802.11s. Warum? 802.11s ist der moderne Standard für Meshing; Ad-Hoc/IBSS stammt aus der Urzeit der WLAN-Entwicklung, 802.11s ist ein weitgehend normierter, moderner Standard. Für uns bedeutet dies schlicht: wir können mehr heute kaufbare Routermodelle unterstützen, da Hersteller zunehmend IBSS nicht mehr (funktional) implementieren.

Nach ersten erfolgreichen Tests werden wir daher in der Nacht zu Freitag eine neue »experimental«-Firmware ausrollen (wie schon in den vergangenen Tagen für »rawhide«-Knoten), die das Meshprotokoll ändert. Dies bedeutet, daß ab Donnerstag abend Knoten mit »rawhide«- oder »experimental«-Firmware nicht mehr mit Knoten mit »testing«- oder »stable«-Firmware werden über Funk sich unterhalten können. Knoten dieser Firmware-Zweige, die nur per WLAN angebunden sind (»mesh-only«), werden nach ca. 3-4 Stunden versuchen, sich per WLAN mit einem anderen Freifunk-AP zu verbinden und ein Firmwareupdate zu installieren. Knoten mit »testing«- oder »stable«-Firmware, die auf einen Knoten mit »rawhide«- oder »experimental«-Firmware als Uplink angewiesen sind, werden erst dann wieder funktionieren, wenn wir auch für »testing«- und »stable«-Knoten das Update aktivieren. Dies ist derzeit für die Nacht zum Samstag geplant, sodaß im Laufe des Samstags das Netz sich aktualisiert haben sollte — und notfalls ein Rollback über den Sonntag erfolgen kann.

Dringende Bitte an Knotenbetreiber, die das automatische Update deaktiviert haben: bitte das Update manuell durchführen, ansonsten droht Verbindungsverlust, spätestens beim Wechsel von »batman v14« zu »batman v15«, der kurzfristig folgen wird.

Es wird in den nächsten ca. 4 Wochen, sofern alles nach Plan läuft, noch weitere anstehende, kurzfristig umzusetzende, Änderungen geben:

  • batman v14 => batman v15 (Hintergrund: Software­aktualisierung)
  • fastd => L2TP/Tunneldigger (Hintergrund: Performance)
  • Aufteilung des FFGT-Meshes (Hintergrund: bessere Skalierung der einzelnen Teilnetze, Performance)
  • Noch nicht entschieden: Einführung von "VXLAN" für kabelbasiertes Meshing (Hintergrund: Störsicherheit, Zukunftsfähigkeit)

Insofern: watch this space :wink:

1 „Gefällt mir“

Aktueller Status: 9 von 29 „experimental“-Knoten haben das Update noch nicht gezogen, 5 davon sind aktuell offline, 2 davon aber schon länger als 12 Stunden.

Aktuelle „Verluste“ also: 3 Knoten, alle im Müritzer Mesh. Das FW-Update geschieht um 4 Uhr, bis 7 Uhr hätten sich die Knoten also aktualisieren sollen. @m.bitterlich, kannst Du mal gucken, was in Tressow (2 der 3 seit 9 Stunden offline seienden Knoten) los ist?

09

Hmm, hat 17194-Tressow-9824 (experimental) sich evtl. gegen 4:24 das Update gezogen, ist mesh-only mit 17194-Tressow-700a (testing) als Uplink? Das würde es zumindest erklären. Ab kommender Nacht sollte der Spuk dann vorbei sein, wenn auch “testing” und “stable” auf 802.11s gebracht werden.

Bei mir hat alles sauber geklappt.
Lu-Hollenbeck-1 mit WAN Uplink hat sich als erstes aktualisiert und Lu-Hollenbeck-2 wurde vom Netz getrennt. Lu-Hollenbeck-2 hat dann vier Stunden später sich die aktuelle Firmware über das Client Netz geholt und sich wieder per Mesh verbunden.

(Ich werde jetzt mal den WAN Uplink wieder aktivieren. Mal schauen wie Stabil der AP dann noch läuft. Oder ob ich ihn neu aufsetzen sollte. Der RAM ist halt sehr knapp. Und ich glaube es wird nicht wirklich besser werden)

Ja, wenn man sich die Grapen anguckt (http://hopglass.4830.org/ffgt/#!/de/map/c46e1f7aac4c), dann ist das schon komisch; wieso z. B. war die Load gerade bei 2, mit nur 1 Client?!

Vielleicht wird des Speicherplatzproblem später entschärft durch L2TP, wir werden sehen.

Ich gehe davon aus, dass durch hin und her konfigurieren da etwas nicht mehr passt. Das interssante ist, dass die 841er mit WLAN Clients Stabil laufen. Sobald man LAN Ports benutzt machen sie dann teilweise Probleme. Hatte ich bei meinen TEST-TEST Knoten bis zum neu aufsetzen auch. Die Modernisierung des Netzes sollte aber dadurch nicht aufgehalten werden.

17194-Tressow-9824 hat sich in der Tat vor ~19,5 Stunden aktualisiert und scheint nur per Mesh verbunden zu sein. Aktuell ist der Link zeitweise wieder da (via 17194-Tressow-42a0, Linkqualität nur 20%/um -88 dBm, stark schankend), sodaß auch 17194-Tressow-c5d8 und 17194-Tressow-b282 das Update ziehen konnten. In ca. 2-3 Stunden sollte dann auch 17194-Tressow-7002 sich aktualisieren — während -9824, -c5d8 und -b282 seit ~20 Stunden offline waren und somit stündlich in den WiFi-Client-Fallback-Modus gingen, muß bei -7002 erst die Karenzzeit von >2 Stunden Offline-Status erreicht werden.

Für des Gütersloher Mesh stehen auch noch einige Updates aus:

Von 312 Knoten um 22:00 auf wieder 315 Knoten um 9:35 — prinzipiell sollte die Operation erfolgreich abgeschlossen sein. Jetzt fehlen noch die mit deaktiviertem Autoupdate sowie die schon längere Zeit offline seienden Knoten.