Hallo zusammen,
es gibt ja das Problem dass sich der Kanal, die BATMAN-Version o.ä. nicht so einfach per Update wechseln lässt, da dann Satelliten, die selber keinen Uplink besitzen, sondern über Mesh das Update herunterladen müssten, eventuell das Update nicht erhalten, und manuell eingegriffen werden muss.
Mir kam da die Idee eines Fallbackmodus.
Zwei Gruppen machen ja keine Probleme:
- Knoten mit Uplink können jederzeit über ihren Uplink nach Updates schauen, klar.
- Knoten ohne Uplink und ohne Mesh in Reichweite haben sowieso keine Funktion. Da geht bei einem Update auch nichts kaputt. Wenn ein Mesh in Reichweite kommt, schlägt automatisch der Fallback wieder an (s.u.). Wenn interne Dienste über den Knoten ausgeliefert werden, dann gehe ich davon aus, dass der Betreiber ein wenig Freifunk mitverfolgt und früher oder später das Update manuell einspielen wird, daher die Funktion nicht benötigt.
Das größte Problem sind die Knoten die keinen Uplink besitzen, aber normalerweise Mesh aufbauen, also einen anderen Freifunkrouter in Reichweite haben. Das bedeutet aber auch, dass die SSID „Freifunk“ sichtbar ist, zu der sich jeder Client ohne Kenntnis von BATMAN auf beliebigem Kanal verbinden kann.
Nun geht man also wie folgt vor, Knoten prüfen einfach regelmäßig:
- Habe ich Uplink an meinem WAN-Port (bzw. Mesh-VPN konfiguriert)? Wenn ja, alles in Ordnung. Fertig.
- Sehe ich wifimesh-xyz und kann mich verbinden (mit Internetzugriff)? Wenn ja, alles in Ordnung. Fertig.
- Sehe ich wifimesh-xyz und kann mich nicht verbinden (oder nur ohne Internetzugriff)? Wenn ja, starte Fallback. (vermutlich Kanalwechsel oder BATMAN-adv Update)
- Sehe ich kein wifimesh-xyz aber eine Freifunk SSID? Wenn ja, starte Fallback. (vermutlich Domänenwechsel)
- (Sehe ich weder wifimesh-xyz, noch Freifunk SSID, aber ein offenes WLAN? Kann man drüber streiten, ob wir es darüber versuchen sollten
)
Der Fallback sieht so aus:
- Der Knoten verbindet sich normal als Client zur SSID Freifunk, wie ein Endgerät. Der AP wird dafür kurz abgeschaltet, damit man den Kanal frei wählen kann.
- Der Knoten nutzt diese Verbindung, um auf Updates zu prüfen. (Wenn keine Internetverbindung hergestellt werden kann, ist die Nachbarswolke inkompatibel und ohne Internet (also alles total kaputt), da können wir nichts machen außer drauf zu hoffen, dass das Internet nur kurzfristig weg ist, wir einen anderen AP mit Internet finden, oder jemand von Hand Kompatibilität herstellt. Abbruch.)
- Wenn ein Update verfügbar ist, dann lade das Update herunter. Fertig. Dann sollte ja die Kompatibilität wieder hergestellt sein.
- Wenn kein Update verfügbar ist, abgebrochen wurde oder ein Fehler beim Update auftrat (z.B. Signatur falsch): Probiere zunächst die anderen APs für die SSID Freifunk aus, und führe den selben Fallback durch. Wenn alle APs ausprobiert wurden: Setze einen Timer (z.B. 4 Stunden) nach dem die ganze Prozedur wieder ausgeführt wird. Das soll verhindern, dass man „einsame Inseln“ dauerhaft offline nehmen kann, wenn man nur die SSID „Freifunk“ in der Nähe ausstrahlt. Dann würde der Knoten nur alle 4h mal „flackern“.
Dieser Fallback hat den Vorteil dass er flexibel ist. Außerdem hat er „Watchdog“-Charakter. Ich denke, dass ein solcher Fallback besser ist, als zu versuchen, irgendwie eine Knotenreihenfolge zu berechnen, in der die Updates ausgegeben werden sollen, zumal da immer irgendwelche Randfälle entstehen können, wenn Strom ausfällt oder so.
Ich denke, spätestens sobald man automatisiert Knoten Domänen wechseln lassen möchte, ist so ein robuster Fallback sicher sinnvoll.
Außerdem müssen natürlich Leute, die Wolken bewusst ohne Internetzugriff betreiben, dieses Feature deaktivieren, da man Internetzugriff braucht um herauszufinden, welches der „richtige“ Teil der Wolke ist.
Gruß
David
