Hi,
ich habe mir nach dem letzten Arbeitstreffen den hoodselector nochmals angeschaut und durch gespielt.
https://pad.ffnw.de/p/hoods-testcases (Ab den Punkt Hoodselector evaluirungsphase)
Wir haben in dem Pad vor ein paar Wochen test-cases eruiert. Es fehlt im Grunde ein testcase wo Clemens und ich, länger drüber diskutiert haben und uns letztlich dafür entschieden hatten diesen Fall erst mal auszuschließen.
Aktuell ist es so, das der hoodselector, wenn er keine geo Position hat, nach benachbarten BSSIDs von Mesh Routern scannt und anschließend die dazu gehörige hood aus dem hoodfile holt. Wenn keine hood zu der gescannten BSSID existiert beendet sich der hoodselector und bleibt weiterhin in der hood die beim Durchlauf zuvor gesetzt wurde.
Wenn wir jetzt einen Mesh-Router haben und einen VPN-Router die miteinander meshen und es wird z.B. eine neue Firmware mit neuen hoods verteilt, kann folgendes Problem auftreten. Der VPN-Router updatet vor dem MeshRouter und wechselt in eine andere neue Hood. Der Mesh-Router wäre somit offline und würde kein Firmware Image bekommen.
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.
Mein vorchlag hier wäre also wenn eine gescannte BSSID gesetzt wird, wird fastd abgeschaltet. Somit kann der Router nur Meshen.
Im nächsten Durchlauf würde der hoodselector dann versuchen eine geoposition zu beziehen. Ist das nicht erfolgreich so würde der Router prüfen ob Batman-adv GWs in Reichweite sind. Ist das der Fall beendet sich der hoodselechtor. Ist es nicht der Fall. So würde der Router wieder in den scann Vorgang gehen. Solange bis er Batman-adv GWs findet oder es keine anderen BSSIDs die unterschiedlich zu eigenen sind gibt.
Kann der Hoodselector eine Geoposition ermitteln, so setzt der Hoodselector wieder die andere Hood und BSSID, die er über die Geoposition bezogen hatte. Die Folge wäre eine Trennung zum Restlichen Netz.
Auch hier hatte ich schon eine mögliche Lösung implementiert. Das wenn der Router eine Hood via Position hat, der Hoodselector prüfen soll ob er Batman-adv GWs sieht. Wenn ja soll er die hood ganz normal setzen. Wenn der hoodselector keine GWs findet soll die o.g. scannroutine einsetzen.
package repo: git diff edbba3be529c0d31c0f529cbaebca6e9edff01cc 58234d27a07fa72f59c7add49da2d02cae0483bc
An dieser stell bin ich mir noch nicht ganz sicher denn es würde wenn ich mich logisch nicht irre eine loop entstehen das. Der Router eine bssid des nachbar Routers setzen würde mit abgeschalteten fastd. Im nächsten Durchlauf hätte der Router ja eine batman-adv GWs und würde somit wieder eine bestehende hood aus seinen hoodfile entnehmen. Dieses Phänomen würde somit immer wieder wechselnd eintreten. Eine Elegante Lösung ist mit noch nicht eingefallen. Evtl. hat jemand von euch eine mögliche Lösung die ich noch nicht gesehen hab.
Schönen Gruß Tarek