Hi zusammen, @Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist. ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen. Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann. vg Tarek
On 12/30/15 11:35, Jan-Tarek Butt wrote:
Hi zusammen,
@Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist.
ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen.
Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann.
vg Tarek
[0] https://wiki.nordwest.freifunk.net/Entwicklung/hoodsystem/ideen
Am Mittwoch, den 30.12.2015, 11:35 +0100 schrieb Jan-Tarek Butt:
Hi zusammen,
@Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist.
ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen. Da würde keine Loop entstehen, weil der Knoten ja durch den gwselector wieder die bssid ändern würde.
Grundsätzlich sollte man aber zu häufiges hin und her wechseln vermeiden, weshalb ich auch die "Hood-Auswahl" lieber auf dem Knoten selber und nicht in der CLOOOUUUD (PHP-Script) sehen würde. Die Idee war ja, dass der Offline Selector eh nur versucht "$irgendwie" ins Freifunk zu kommen, damit er die aktuellen Hood-Informationen bekommen kann. Auf den neuen Informationen basierend würde er sein Netz aufspannen. Wenn keine Nachbarn da sind, sollte in Regelmäßigen Abständen nach Netzen gesucht werden, um ggfs neue Hood-Informationen zu bekommen. Tim
Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann.
vg Tarek
Können wir gegen 2 eine kurze telko machen? Am 30.12.2015 11:48 schrieb "Tim Niemeyer" <tim.niemeyer@mastersword.de>:
Am Mittwoch, den 30.12.2015, 11:35 +0100 schrieb Jan-Tarek Butt:
Hi zusammen,
@Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist.
ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen. Da würde keine Loop entstehen, weil der Knoten ja durch den gwselector wieder die bssid ändern würde.
Grundsätzlich sollte man aber zu häufiges hin und her wechseln vermeiden, weshalb ich auch die "Hood-Auswahl" lieber auf dem Knoten selber und nicht in der CLOOOUUUD (PHP-Script) sehen würde.
Die Idee war ja, dass der Offline Selector eh nur versucht "$irgendwie" ins Freifunk zu kommen, damit er die aktuellen Hood-Informationen bekommen kann. Auf den neuen Informationen basierend würde er sein Netz aufspannen. Wenn keine Nachbarn da sind, sollte in Regelmäßigen Abständen nach Netzen gesucht werden, um ggfs neue Hood-Informationen zu bekommen.
Tim
Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Bzw. das wird auch schon knapp... Ich würde den kompletten Verbindungsaufbau über br-wan machen, einschließlich gwselection. Die gwselection ist das Neue, der übrige Verbindungsaufbau passiert schon über br-wan. Die gwselection braucht quasi keine Bandbreite und die Daten sind völlig unkritisch, da öffentlich. Ich weiß, dass es generell kritisch ist br-wan direkt zu verwenden. Die gwselection wird allerdings der neue erste Schritt im Verbindungsaufbau, der bisher ohnehin schon über br-wan statt fand. Außerdem spart uns das unabhängig von dem "ich verbinde mich neu Problem" eine Menge overhead und neu Verbinderei. Das Problem besteht trotzdem, da es Eintritt sobald die VPN Verbindung besteht. Das heißt in dem Zeitfenster von VPN verbunden und gwselection Daten abgerufen und neu verbinden sind zwei Hoods auf L2 verbunden. Im Einzelfall mag das noch kurzzeitig händelbar sein, wenn das eine Vielzahl an Routern macht weil das Problem systematisch auftritt, nicht mehr. Am 30.12.2015 12:48 schrieb "Simon Kurka" <simon@kurka.cc>:
Können wir gegen 2 eine kurze telko machen? Am 30.12.2015 11:48 schrieb "Tim Niemeyer" <tim.niemeyer@mastersword.de>:
Am Mittwoch, den 30.12.2015, 11:35 +0100 schrieb Jan-Tarek Butt:
Hi zusammen,
@Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist.
ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen. Da würde keine Loop entstehen, weil der Knoten ja durch den gwselector wieder die bssid ändern würde.
Grundsätzlich sollte man aber zu häufiges hin und her wechseln vermeiden, weshalb ich auch die "Hood-Auswahl" lieber auf dem Knoten selber und nicht in der CLOOOUUUD (PHP-Script) sehen würde.
Die Idee war ja, dass der Offline Selector eh nur versucht "$irgendwie" ins Freifunk zu kommen, damit er die aktuellen Hood-Informationen bekommen kann. Auf den neuen Informationen basierend würde er sein Netz aufspannen. Wenn keine Nachbarn da sind, sollte in Regelmäßigen Abständen nach Netzen gesucht werden, um ggfs neue Hood-Informationen zu bekommen.
Tim
Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Mittwoch, den 30.12.2015, 13:12 +0100 schrieb Simon Kurka:
Bzw. das wird auch schon knapp...
Ich würde den kompletten Verbindungsaufbau über br-wan machen, einschließlich gwselection. Die gwselection ist das Neue, der übrige Verbindungsaufbau passiert schon über br-wan. Die gwselection braucht quasi keine Bandbreite und die Daten sind völlig unkritisch, da öffentlich.
Ich weiß, dass es generell kritisch ist br-wan direkt zu verwenden. Die gwselection wird allerdings der neue erste Schritt im Verbindungsaufbau, der bisher ohnehin schon über br-wan statt fand. Außerdem spart uns das unabhängig von dem "ich verbinde mich neu Problem" eine Menge overhead und neu Verbinderei.
Das Problem besteht trotzdem, da es Eintritt sobald die VPN Verbindung besteht. Das heißt in dem Zeitfenster von VPN verbunden und gwselection Daten abgerufen und neu verbinden sind zwei Hoods auf L2 verbunden. Im Einzelfall mag das noch kurzzeitig händelbar sein, wenn das eine Vielzahl an Routern macht weil das Problem systematisch auftritt, nicht mehr.
Ne, weil in den Hood-Informationen ja auch enthalten ist, welcher VPN Server verwendet werden muss. Ausserdem Meshen zwei Knoten nicht, welche in unterschiedlichen Hoods sind. Selbstverständlich muss bei einem Hood-Wechsel immer erst mal VPN und Mesh runtergefahren werden, dann umkonfiguriert und erst danach wieder hoch gefahren werden. Der Online Selector ist quasi mehr so ein Einbrech-Tool, um in eine vorhandene Hood einzutreten, um dort aktuelle Hood-Informationen zu bekommen. Tarek hatte vorhin noch die Idee, dass die Hood-Informationen zunächst nur fest in die Firmware reingeschrieben werden. Wenn es eine neue Hood gibt, würde es eine neue Firmware geben. Das ist natürlich kein Zustand, aber erstmal ein guter Übergang. Tim
Am 30.12.2015 12:48 schrieb "Simon Kurka" <simon@kurka.cc>: Können wir gegen 2 eine kurze telko machen?
Am 30.12.2015 11:48 schrieb "Tim Niemeyer" <tim.niemeyer@mastersword.de>: Am Mittwoch, den 30.12.2015, 11:35 +0100 schrieb Jan-Tarek Butt: > Hi zusammen, > > @Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher > bin ob du noch auch unser dev ML bist. > > ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell > an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf > zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / > offline selector. Der online selector ist relativ trivial und auch > bereits größtenteils implementiert. Bei dem offline selector überlege > ich schon länger wie man den implementieren sollte und bisher ist mir > noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich > gearbeitet hatte, scannt nach benachbarten wlans mit der identischen > ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal > quallity und das auch nur wenn es sich um ein reinen mesh Router > handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde > wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, > würde der Router automatisch die bssid des Nachbar VPN Routers > übernehmen. Kommt dann wieder der vpn des ersten Routers online würde > somit automatisch eine loop zwischen zwei hoods entstehen. Da würde keine Loop entstehen, weil der Knoten ja durch den gwselector wieder die bssid ändern würde.
Grundsätzlich sollte man aber zu häufiges hin und her wechseln vermeiden, weshalb ich auch die "Hood-Auswahl" lieber auf dem Knoten selber und nicht in der CLOOOUUUD (PHP-Script) sehen würde.
Die Idee war ja, dass der Offline Selector eh nur versucht "$irgendwie" ins Freifunk zu kommen, damit er die aktuellen Hood-Informationen bekommen kann. Auf den neuen Informationen basierend würde er sein Netz aufspannen. Wenn keine Nachbarn da sind, sollte in Regelmäßigen Abständen nach Netzen gesucht werden, um ggfs neue Hood-Informationen zu bekommen.
Tim
> > Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann. > > vg > Tarek >
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Tarek hatte vorhin noch die Idee, dass die Hood-Informationen zunächst nur fest in die Firmware reingeschrieben werden. Wenn es eine neue Hood gibt, würde es eine neue Firmware geben. Das ist natürlich kein Zustand, aber erstmal ein guter Übergang.
Ich habe mir überlegt, ähnlich wie Tim es bereits oben wieder gegeben hat, das ein json File bereits beim compilieren in der Firmware hinterlegt wird. Allerdings soll es ähnlich zum autoupdater aktualisiert werden. D.h. ein über cron aufgerufenes Programm fragt in einem Intervall über hood.ffnw ein Manifest File ab. befindet sich in dem Manifest File eine neuere Version als auf dem Router werden die Signaturen geprüft die das Manifest unterschrieben haben. Sind genug valide Signaturen dabei, Lädt der Router das neue json File herunter und erstellt eine Checksumme davon. Anschließend wird die Checksumme mit der aus dem signierten Manifest verglichen. Wenn die hashes identisch sind wird die Datei auf dem Router durch die neue ersetzt. Das ist zwar ein wenig zentralistisch aber es bietet uns überhaupt erst mal eine Basis mit der wir arbeiten können. vg Tarek
Tarek hatte vorhin noch die Idee, dass die Hood-Informationen zunächst nur fest in die Firmware reingeschrieben werden. Wenn es eine neue Hood gibt, würde es eine neue Firmware geben. Das ist natürlich kein Zustand, aber erstmal ein guter Übergang.
Ich habe mir überlegt, ähnlich wie Tim es bereits oben wieder gegeben hat, das ein json File bereits beim compilieren in der Firmware hinterlegt wird. Allerdings soll es ähnlich zum autoupdater aktualisiert werden. D.h. ein über cron aufgerufenes Programm fragt in einem Intervall über hood.ffnw ein Manifest File ab. befindet sich in dem Manifest File eine neuere Version als auf dem Router werden die Signaturen geprüft die das Manifest unterschrieben haben. Sind genug valide Signaturen dabei, Lädt der Router das neue json File herunter und erstellt eine Checksumme davon. Anschließend wird die Checksumme mit der aus dem signierten Manifest verglichen. Wenn die hashes identisch sind wird die Datei auf dem Router durch die neue ersetzt.
Das ist zwar ein wenig zentralistisch aber es bietet uns überhaupt erst mal eine Basis mit der wir arbeiten können.
Das Setup ist so leider noch nicht für Franken umsetzbar. Eine mögliche Lösung haben wir im Wiki formuliert. vg Tarek
Moin Tarek Am Donnerstag, den 31.12.2015, 14:53 +0100 schrieb Jan-Tarek Butt:
Das Setup ist so leider noch nicht für Franken umsetzbar. Eine mögliche Lösung haben wir im Wiki formuliert. Das ist nicht so schlimm. Wir haben ja so etwas, was Ihr jetzt baut bereits auf Basis des fastdstart.sh. Wir wollen es natürlich aber langfristig dezentral haben.
Tim
Hi, Der gwselector ist jetzt weitestgehend fertig. Es fehlt nur noch der Part zum setzen der fastd config. Die Mesh Router prüfen jetzt ob über batctl gwl gateways ausfindig zu machen sind. Wenn keine zu finden sind scannen die Mesh Router nach benachbarten freifunk-Routern und übernehmen deren bssid. Das tun sie solange bis gateways bei batctl gwl erscheinen. Ich habe das soeben in einer Konstellation von 2 mesh Routern und einem VPN Router erfolgreich getestet. Leider hab ich hier gerade keine dualband Geräte liegen. Kann das evtl. jemand testen der 3 oder mehr WDR Geräte hat ? bzw. oder die Geräte zum Nächsten Treffen am Freitag mitbringen ? vg Tarek
Hi, Ich hab den gwselector über Nacht fertig gestellt.
Leider hab ich hier gerade keine dualband Geräte liegen. Kann das evtl. jemand testen der 3 oder mehr WDR Geräte hat ?
Hat das schon jemand getestet ?
bzw. oder die Geräte zum Nächsten Treffen am Freitag mitbringen ?
oder bringt jemand Router mit ? vg Tarek
Einen könnt ich in jedem Fall mitbringen. Zur not auch zwei. Am 08.01.2016 10:47 vorm. schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Hi,
Ich hab den gwselector über Nacht fertig gestellt.
Leider hab ich hier gerade keine dualband Geräte liegen. Kann das evtl. jemand testen der 3 oder mehr WDR Geräte hat ?
Hat das schon jemand getestet ?
bzw. oder die Geräte zum Nächsten Treffen am Freitag mitbringen ?
oder bringt jemand Router mit ?
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
participants (4)
-
Jan-Tarek Butt -
Malte Modler -
Simon Kurka -
Tim Niemeyer