Am Dienstag, 5. April 2016, 21:07:16 CEST schrieb Jan-Tarek Butt via Dev:
Nun kommt ein Lösungsvorschlag den ich in einer früheren Version des Hoodselectors schon einmal implementiert hatte.
Wenn der Hoodselector keine geo Position hat, scannt er nach benachbarten BSSIDs von Mesh Routern um anschließend die dazu gehörige hood aus dem hoodfile zu holt. Wenn keine hood zu der gescannten BSSID existiert setzt der Router die gescannte BSSID mit der default Hood. Anschließend beendet sich der hoodselector.
Problem hierbei ist das zwei Hoods über Layer2 verbunden werden könnten. Was ein wahrscheinlichen Ausfall beider betroffenen Hoods zur folge hätte.
Hi,
ich glaube wir haben eine Lösung gefunden, darum versuche den Thread mal zusammenzufassen.
Zuerst eine Korrektur zum obigen Verhalten: Wir setzen niemals eine Hood und überschreiben die BSSID der Hood mit irgendeiner anderen BSSID. Auch nicht im Default-Hood Modus, denn dieses Verhalten ist Fehleranfällig und nicht notwendig. Ich glaube das ist so auch aktuell nicht implementiert, checke das aber nochmal.
Jetzt zum eigentlichen Problem. Wir haben ja aktuell drei Modi: 1. Standard-Mode (Position bekannt und Hood zu Position vorhanden) 2. Scan-Mode (Position unbekannt aber Freifunkrouter in Reichweite, die auf eine bekannte Hood konfiguriert sind) 3. Default-Hood Mode (Position unbekannt, kein Freifunkrouter in Reichweite)
In allen obigen Modi wird immer eine Hood gesetzt. Das was Tarek und Simon beschreiben ist quasi ein vierter Modus. Ich würde ihn als "Maintenance-Modus" bezeichnen.
Dieser Modus ist der Fehlende Modus zwischen den Modi 2 und 3 und hat das Ziel mit minimalen Informationen (nur die SSID des potentiellen Mesh-Netzes mesh.ffnw ist bekannt) eine Verbindung zum Netz herzustellen um das Hoodfile zu updaten. Dabei wird keine Hood gesetzt. Stattdessen werden alle Verbindungen (VPN und MoL) beendet und dann eine Mesh-Verbindung zu potentiellen (unbekannten) Hoods hergestellt. Diese erkennen wir durch die bekannte Mesh- BSSID (mesh.ffnw). Im Anschluss wird geprüft ob das Hoodfile geupdated werden kann (aktuell würden wir also prüfen ob der Firmware-Server erreichbar ist).
Ist der Firmware-Server nicht erreichbar bleiben wir im Maintenance-Mode und versuchen die nächste potentielle unbekannte Hood falls vorhanden. Sind keine weiteren Hoods vorhanden, konfigurieren wir den Router zurück auf seine ursprüngliche Hood und versuchen es zu einem späteren Zeitpunkt. Ist der Firmware-Server erreichbar updaten wir die Firmware und lassen den Hoodselector erneut laufen (das passiert dann ja automatisch).
Tim beschreibt den selben Modus, allerdings mit einem anderen Verfahren um an das neueste Hoodfile zu kommen. Das Verfahren ist dezentraler, allerdings auch komplexer in der Implementation und ich bin mir nicht ganz sicher ob das aufspannen eines weiteren Client-Netzes nicht auch negative Effekte auf die Performance hat (das ist aber nur Spekulation, ich habe das nicht gecheckt wie der Treiber sich da verhält).
Ich habe die Testcases mal geupdated und mit dem neuen Modus ergeben sich vier Modi, die der Hoodselektor erkennen und der Reihe nach probieren kann:
1. Standard-Mode (Position bekannt und Hood zu Position vorhanden) 2. Scan-Mode (Position unbekannt aber Freifunkrouter in Reichweite die auf eine bekannte Hood konfiguriert sind) 3. Maintenance-Mode (Position unbekannt aber Freifunkrouter in Reichweite, die jedoch alle auf eine unbekannte Hood konfiguriert sind) 4. Default-Hood Mode (Position unbekannt, kein Freifunkrouter in Reichweite)
https://pad.ffnw.de/p/hoods-testcases
Tarek willst du das Verhalten implementieren?
Viele Grüße Clemens