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
Hoi,
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.
Würden dann die neue Hood und die default-Hood unterschiedliche BSSIDs haben? Dann würden die doch AFAIR nicht meshen?
Könnte alternativ der Router sich dann nicht als Client ins Netz hängen und versuchen, sich zu geolocaten oder dergleichen?
gruß
On 04/05/16 22:25, Bjoern Franke via Dev wrote:
Hoi,
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.
Würden dann die neue Hood und die default-Hood unterschiedliche BSSIDs haben? Dann würden die doch AFAIR nicht meshen?
Genau, das ist ja das was wir mit den hoods anstreben.
Könnte alternativ der Router sich dann nicht als Client ins Netz hängen und versuchen, sich zu geolocaten oder dergleichen?
Wäre eine möglichkeit für den für den zweiten fall im scannmode. Diese variante würde ich allerdings meiden wollen der der Freifunk Router in seinen eigentlichen Aktivitäten dann vollständig unterbrochen wäre. Zudem kommt das der Router ja nur in den client mode gehen sollte wenn es eine neue Firmware gibt. Das kann der Router allerdings vor her ja auch nicht wissen.
vg Tarek
Moin,
wir könnten das Hoodfile noch erweitern mit einem disabled Flag. Dann können wir die BSSID von zukünftigen Hoods, welche wir ja schon mal bestimmen könnten auf die Router verteilen.
Diese Disabled Hoods werden standardmäßig ignoriert.
Wenn nun der VPN Router sich updatet und eine neue Hood bekommt, dann wäre die mögliche BSSID bereits auf dem Mesh Router bekannt. Dieser könnte sich das Meshen und darüber sich das update laden.
Am 05.04.2016 um 21:07 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
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
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
wir könnten das Hoodfile noch erweitern mit einem disabled Flag. Dann können wir die BSSID von zukünftigen Hoods, welche wir ja schon mal bestimmen könnten auf die Router verteilen.
Diese Disabled Hoods werden standardmäßig ignoriert.
Wenn nun der VPN Router sich updatet und eine neue Hood bekommt, dann wäre die mögliche BSSID bereits auf dem Mesh Router bekannt. Dieser könnte sich das Meshen und darüber sich das update laden.
Die BSSID ist ja so oder so schon bekannt das diese vom Router selbst via mesh.ffnw angezeigt wird.
vg Tarek
On 04/05/16 22:26, Johannes Rudolph wrote:
Moin,
wir könnten das Hoodfile noch erweitern mit einem disabled Flag. Dann können wir die BSSID von zukünftigen Hoods, welche wir ja schon mal bestimmen könnten auf die Router verteilen.
Diese Disabled Hoods werden standardmäßig ignoriert.
Wenn nun der VPN Router sich updatet und eine neue Hood bekommt, dann wäre die mögliche BSSID bereits auf dem Mesh Router bekannt. Dieser könnte sich das Meshen und darüber sich das update laden.
Oder hab ich das evtl. falsch verstanden?
Hi
Am 5. April 2016 21:07:16 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
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.
Das bringt ja nix, wenn ein dritter Knoten mit default bssid und fast in der Nähe ist.
Alternativer Vorschlag, so wie wir es im Süden machen wollen:
Jeder Knoten spannt ein Config AP Netz auf. Auf dem Netz kann man keine IP beziehen und wird auch nicht ins Freifunk geroutet. Aber man kann darüber die aktuellsten Hood Informationen downloaden, die ja auf jedem Knoten liegen sollten. Anschliessend normal konfigurieren.
Tim
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
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.
Das bringt ja nix, wenn ein dritter Knoten mit default bssid und fast in der Nähe ist.
Wieso nicht ?
Alternativer Vorschlag, so wie wir es im Süden machen wollen:
Jeder Knoten spannt ein Config AP Netz auf. Auf dem Netz kann man keine IP beziehen und wird auch nicht ins Freifunk geroutet. Aber man kann darüber die aktuellsten Hood Informationen downloaden, die ja auf jedem Knoten liegen sollten. Anschliessend normal konfigurieren.
Das wäre natürlich die wünschenswerter Lösung, da diese sehr schön dezentral ist. Es würde ja reichen wenn die Router einmal täglich das config netzt aufspannen. Für ne Stunde aufspannen, um eine Treiber /Hardware Limitierung zu vermeiden.
Ähnliches wäre in Zukunft anzustreben.
Wie Löst ihr dann das Problem mit den Router die nur meshen, sich aber Tatsächlich an der grenze einer anderen hood befinden. Wo der eigentliche VPN Router nicht in der identischen hood sitzt.
vg Tarek
moin,
Zitat von Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Problem hierbei ist das zwei Hoods über Layer2 verbunden werden könnten. Was ein wahrscheinlichen Ausfall beider betroffenen Hoods zur folge hätte.
wir sollten hier eine Möglichkeit finden das es nicht passieren kann durch: falsch konfiguration oder mutwilligkeiten
Warum übernehmen wir nicht einfach die nächst beste BSSID vom Adhoc WLAN mit Namen mesh.ffnw?
So war es mal gedacht und ich habe nicht ein Argument dagegen gehört oder gelesen.
On 04/06/16 12:15, Simon Kurka via Dev wrote:
Warum übernehmen wir nicht einfach die nächst beste BSSID vom Adhoc WLAN mit Namen mesh.ffnw?
So war es mal gedacht und ich habe nicht ein Argument dagegen gehört oder gelesen.
Weil das spätestens nach dem nächsten durch lauf nicht mehr Funktionieren würde das der Router dann ja wieder ein Netz Zugang hat. Darüber potentiell Koordinaten beziehen könnte (wenn er nicht schon welche hat) und sich wieder seine hood via Position setzen würde.
vg Tarek
On 07.04.2016 08:51, Jan-Tarek Butt via Dev wrote:
On 04/06/16 12:15, Simon Kurka via Dev wrote:
Warum übernehmen wir nicht einfach die nächst beste BSSID vom Adhoc WLAN mit Namen mesh.ffnw?
So war es mal gedacht und ich habe nicht ein Argument dagegen gehört oder gelesen.
Weil das spätestens nach dem nächsten durch lauf nicht mehr Funktionieren würde das der Router dann ja wieder ein Netz Zugang hat. Darüber potentiell Koordinaten beziehen könnte (wenn er nicht schon welche hat) und sich wieder seine hood via Position setzen würde.
Und wo ist das Problem? Oder wo ist der Unterschied, wenn die Hood bekannt sein muss?!
Oberstes Ziel von Mesh-Routern sollte sein einen Netzzugang zu bekommen, über welche Hood auch immer. Hood Auswahl ist Sache der VPN-Router (oder reiner Offline Router, wobei die echt uninteressant sind...)
Hey, mir ist gerade was bei dem hoodselector aufgefallen: Ich habe einen Router mit VPN, der in einer Hood OS gelandet ist. Dann stelle ich hier 2 only mesh router auf die keinen Uplink haben. Diese ziehen sich wohl keine Koordinaten und meshen nicht mit dem Uplink-Router.
Was kann das sein?
Stefan
Am 07.04.2016 um 09:50 schrieb Simon Kurka via Dev:
On 07.04.2016 08:51, Jan-Tarek Butt via Dev wrote:
On 04/06/16 12:15, Simon Kurka via Dev wrote:
Warum übernehmen wir nicht einfach die nächst beste BSSID vom Adhoc WLAN mit Namen mesh.ffnw?
So war es mal gedacht und ich habe nicht ein Argument dagegen gehört oder gelesen.
Weil das spätestens nach dem nächsten durch lauf nicht mehr Funktionieren würde das der Router dann ja wieder ein Netz Zugang hat. Darüber potentiell Koordinaten beziehen könnte (wenn er nicht schon welche hat) und sich wieder seine hood via Position setzen würde.
Und wo ist das Problem? Oder wo ist der Unterschied, wenn die Hood bekannt sein muss?!
Oberstes Ziel von Mesh-Routern sollte sein einen Netzzugang zu bekommen, über welche Hood auch immer. Hood Auswahl ist Sache der VPN-Router (oder reiner Offline Router, wobei die echt uninteressant sind...)
Am Donnerstag, 7. April 2016, 11:49:56 CEST schrieb Stefan via Dev:
mir ist gerade was bei dem hoodselector aufgefallen: Ich habe einen Router mit VPN, der in einer Hood OS gelandet ist. Dann stelle ich hier 2 only mesh router auf die keinen Uplink haben. Diese ziehen sich wohl keine Koordinaten und meshen nicht mit dem Uplink-Router.
Was kann das sein?
Hi,
in der Theorie kann man jetzt einfach die Testcases ablaufen und schauen was passieren sollte. In diesem Fall sollte entweder der Scan-Mode oder der Maintenance-Mode erfolgreich sein, je nachdem welchen Datenbestand die Mesh- Router haben. Siehe: https://pad.ffnw.de/p/hoods-testcases
Falls du dieses Szenario gerade testest: der Hoodselector so wie er jetzt im Git ist, tut noch nicht ganz was wir nach den Testcases erwarten. Darum bitte noch keine Bugs diskutieren, das macht jetzt noch keinen Sinn.
Viele Grüße Clemens
Hi,
oh Gott, da blicke ich nimma durch :D Normalerweise sollte er ja nach "mesh.ffnw" scannen und sich darüber die Informationen ziehen.
Das tut er nur leider nicht. Ich bin grade nur dabei, hier ein wenig mit zu spielen.
Stefan
Am 07.04.2016 um 12:06 schrieb Clemens John via Dev:
Am Donnerstag, 7. April 2016, 11:49:56 CEST schrieb Stefan via Dev:
mir ist gerade was bei dem hoodselector aufgefallen: Ich habe einen Router mit VPN, der in einer Hood OS gelandet ist. Dann stelle ich hier 2 only mesh router auf die keinen Uplink haben. Diese ziehen sich wohl keine Koordinaten und meshen nicht mit dem Uplink-Router.
Was kann das sein?
Hi,
in der Theorie kann man jetzt einfach die Testcases ablaufen und schauen was passieren sollte. In diesem Fall sollte entweder der Scan-Mode oder der Maintenance-Mode erfolgreich sein, je nachdem welchen Datenbestand die Mesh- Router haben. Siehe: https://pad.ffnw.de/p/hoods-testcases
Falls du dieses Szenario gerade testest: der Hoodselector so wie er jetzt im Git ist, tut noch nicht ganz was wir nach den Testcases erwarten. Darum bitte noch keine Bugs diskutieren, das macht jetzt noch keinen Sinn.
Viele Grüße Clemens
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 04/07/16 12:06, Clemens John via Dev wrote:
Am Donnerstag, 7. April 2016, 11:49:56 CEST schrieb Stefan via Dev:
mir ist gerade was bei dem hoodselector aufgefallen: Ich habe einen Router mit VPN, der in einer Hood OS gelandet ist. Dann stelle ich hier 2 only mesh router auf die keinen Uplink haben. Diese ziehen sich wohl keine Koordinaten und meshen nicht mit dem Uplink-Router.
Was kann das sein?
Falls du dieses Szenario gerade testest: der Hoodselector so wie er jetzt im Git ist, tut noch nicht ganz was wir nach den Testcases erwarten.
Das ist nich ganz korrekt er tut genau das was in den Testcases erwartet wird. Nur sind wir gerade dabei zu diskutieren wie der hoodselector sich bei genau den Fall den Stefan gerade beschrieben hat verhalten soll.
vg Tarek
Am Donnerstag, 7. April 2016, 09:50:19 CEST schrieb Simon Kurka via Dev:
Oberstes Ziel von Mesh-Routern sollte sein einen Netzzugang zu bekommen
Richtig. Allerdings weiß der Hoodselector nicht ob es sich um einen WLAN-Mesh- Router oder um einen MoL-Router oder um einen VPN-Router handelt. Natürlich kann man das rausfinden und die Programmlogik danach bauen. Das würde aber eine ganze Reihe neuer Zustände in den Hoodselector bringen, weshalb wir einen anderen Ansatz verfolgen.
Unser Ansatz ist, dass wir den Router immer auf eine bekannte Hood konfigurieren indem wir mittels der Position oder Anhand der Signale umliegender Freifunk Router eine bekannte Hood auswählen. Selbst wenn wir weder eine Position noch Signale umliegender Freifunk Router haben, landet unser Router in einer bekannten Hood, der Default Hood. Dadurch brauchen wir nicht zu wissen wie der Router angebunden ist, da wir alle sicherheitsrelevanten Parameter kennen und entsprechend der Hood konfigurieren können. Dieses Verhalten lässt sich mittels dreier Zustände und völlig ohne Abhängigkeiten zu Routingprotokollen abbilden.
Jetzt gibt es noch einen vierten Sonderzustand. Wenn wir keine Position und auch kein Signal einer bekannten Hood bekommen, aber ein Signal einer unbekannten Hood existiert, dann haben wir offensichtlich nicht die neuesten Informationen. In diesem Fall deaktivieren wir alles was böse Dinge tun könnte und versuchen mit einer Sondermethode die neuesten Informationen zu holen.
Viele Grüße Clemens
On 04/07/16 09:50, Simon Kurka via Dev wrote:
On 07.04.2016 08:51, Jan-Tarek Butt via Dev wrote:
On 04/06/16 12:15, Simon Kurka via Dev wrote:
Warum übernehmen wir nicht einfach die nächst beste BSSID vom Adhoc WLAN mit Namen mesh.ffnw?
So war es mal gedacht und ich habe nicht ein Argument dagegen gehört oder gelesen.
Weil das spätestens nach dem nächsten durch lauf nicht mehr Funktionieren würde das der Router dann ja wieder ein Netz Zugang hat. Darüber potentiell Koordinaten beziehen könnte (wenn er nicht schon welche hat) und sich wieder seine hood via Position setzen würde.
Und wo ist das Problem?
Das der Router zum Intervall der hoodselectors on und offline geht, ohne ein zustand zu halten.
Oder wo ist der Unterschied, wenn die Hood bekannt sein muss?!
Oberstes Ziel von Mesh-Routern sollte sein einen Netzzugang zu bekommen, über welche Hood auch immer.
Nicht ganz. Oberstes Ziel sollte sein das die Router möglichst ein mesh-Netzwerk Bauen. Den dienst eines Internet Zugang ist in diesem Kontext nicht zwingend relevant, sondern eher ein Nice to Have Feature.
Hood Auswahl ist Sache der VPN-Router (oder
reiner Offline Router, wobei die echt uninteressant sind...)
Im hoodselector wird z.Z. nicht zwischen mesh und vpn Router unterscheiden.
Die Variante die Ich Anfanges angestrebt hatte war das die Router Möglichst versuchen ein Mesh Zu bilden. Baut ein Router eine VPN in einer lokalen Mesh Wolke auf so ändert dieser seine BSSID zu der im zugeteilten Hood und alle umliegenden Mesh Router wechseln wenn diese offline sind nach und nach in die neue Hood. Diese Implementierung wurde von Clemens allerdings Argumentativ zerlegt.
vg Tarek
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
On 06.04.2016 17:38, Clemens John via Dev wrote:
Jetzt zum eigentlichen Problem. Wir haben ja aktuell drei Modi:
- Standard-Mode (Position bekannt und Hood zu Position vorhanden)
- 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)
- Standard-Mode (Position bekannt und Hood zu Position vorhanden)
- 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)
Der einzige Unterschied zwischen Scan-Mode und Maintenance-Mode ist selber konstruiert (bekannte Hood / unbekannte Hood).
Ich sehe dafür keine Notwendigkeit.
Eine möglicherweise höhere Fehleranfälligkeit kann ich nicht erkennen.
Der Implementierungsaufwand ist definitiv größer (ein Case mehr und der Scan-Mode hätte ein Abfrage mehr). Ein praktisches Problem kann sich auch ergeben:
Router A kennt seine Position nicht. Router B ist mit sehr guter Link-Quality in Reichweite und sendet eine unbekannte Hood. Router C ist mit sehr schlechter Link-Quality in Reichweite und sendet eine bekannte Hood.
Router A würde die schlechte Verbindung nutzen. Das kann dazu führen, dass Router A niemals das neue Hoodfile erhält. Letztlich besteht für Router A keine Notwendigkeit die schlechte, statt der guten Verbindung zu nutzen.
Mein Vorschlag:
1. Standard-Mode (Position bekannt und Hood zu Position vorhanden) 2. Scan-Mode (Position unbekannt aber Freifunkrouter in Reichweite) 3. Default-Hood Mode (Position unbekannt, kein Freifunkrouter in Reichweite)
Außerdem ist der Standard-Mode nur für Router mit Uplink relevant. Mesh-Router sollten sofort in den Scan-Mode wechseln, da es wichtiger ist überhaupt eine Verbindung haben, als in der richtigen Hood laut Geodaten zu sein.
Zu Tareks Problem, dass ein VPN Router ohne Geodaten zwei Hoods kurzschließen könnte: Bevor ein Router mit einer Hood per WLAN mesht, hat der VPN-Router den Server zu wechseln. Erst anschließend darf die Mesh-Verbindung aufgebaut werden. Ist der passende Server nicht bekannt (z. B. weil das Hoodfile veraltet ist) kann der Server nicht gewechselt werden (wohin auch?). Ein Verzicht auf VPN und der Umstieg auf reines Meshing ist unsinnig. Es bleibt Default-Mode (3). Der Router kann sich ggf. ein Update des Hoodfiles ziehen und dann den Server wechseln.
Hi,
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.
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.
Das ist aktuell nicht enthalten. In einem älteren Commit ist diese Implementierung noch existent.
Jetzt zum eigentlichen Problem. Wir haben ja aktuell drei Modi:
- Standard-Mode (Position bekannt und Hood zu Position vorhanden)
Hier wird die Default hood ebenfalls gesetzt wenn es zu den bestehenden Koordinaten keine eigene hood gibt.
- 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).
Das könnte man mit ein paar wenigen code lines schnell realisieren, wo VPN und MoL und MoW abgeschaltet werden plus die Nachbar BSSID und bei der Terminierung der hoodselectors wird ein sleep 3 & autoupdater -f befehl abgesetzt. Somit würde der Router entsprechen updaten und das neue hoodfile besitzen.
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).
Der Test nach verschiedenen BSSIDs ist bereits Existenz, sowie der Intervall Wechsel für unterschiedliche BSSIDs nämlich einmal pro Aufruf des hoodselectors.
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).
Bei Tims Variante gibt es einen (finde ich persönlich) Vorteil die Router bleibe die ganze zeit in ihren Normalbetrieb.
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:
- Standard-Mode (Position bekannt und Hood zu Position vorhanden)
- 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?
Ich würde erst nochmal die Diskussion weiter führen falls noch Ergänzungen oder andere Vorschläge folgen.
vg Tarek
Hi,
Ich habe den hoodselector nun noch einmal angepasst.
Jetzt sollten alle notwendigen Fällen abgedeckt sein.
U.a. auch: Wenn der VPN Router eine andere neuere Hood als der mesh Router hat. Beendet der meshRouter fastd, setzt die BSSID des Nachbarn sofern die hood zur BSSID nicht bekannt ist. wartet 15sec und setzt einen autoupdater -f & Befehl vor der Terminierung ab.
@Stefan das sollte jetzt deinen fall lösen.
vg Tarek
Hey,
ich würde Montag mal eine Test Firmware bauen und dann einmal testen.
Danke :)
Am 9. April 2016 23:32:54 MESZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Ich habe den hoodselector nun noch einmal angepasst.
Jetzt sollten alle notwendigen Fällen abgedeckt sein.
U.a. auch: Wenn der VPN Router eine andere neuere Hood als der mesh Router hat. Beendet der meshRouter fastd, setzt die BSSID des Nachbarn sofern die hood zur BSSID nicht bekannt ist. wartet 15sec und setzt einen autoupdater -f & Befehl vor der Terminierung ab.
@Stefan das sollte jetzt deinen fall lösen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Hier auch nochmal ein pad wie der hoodselector jetzt arbeitet.
https://pad.freifunk.net/p/hoodselector
vg Tarek
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
Johannes Rudolph -
picard -
Simon Kurka -
Stefan -
Tim Niemeyer