Neue Testing Firmware Hoodselector Fix und Update Fest
Moin zusammen, ich habe gerade eine neue Testing gebaut. Ihr findet sie hier: Meine Änderungen zum Aktuellen stable findet ihr hier: https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703 <https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703> Download: https://firmware.ffnw.de/20170227_testing/ Meine Änderungen / Anpassungen / Ergänzungen: Hoodselector: Ich habe folgendes umgebaut, was für die Praxis mir aktuell deutlich sin voller erscheint: Wenn ein Router ein VPN Router ist und eingetragene Koordinaten hat, wird nich überprüft ob es einen Mesh Konflikt per Mesh on LAN/WAN gibt. Sicherlich kann es hierdurch zu Hoodkurzschlüssen kommen, allerdings passiert das aktuell bei Firmware updates sehr oft und ich und Stefan sind den ganzen Tag dabei diese Hoodkurzschlüsse auf den Supernodes zu trennen. Dadurch das der VPN Router dieses nicht mehr prüft haben die MeshKnoten um ihn herum es einfacher die richtige Hood zu finden, wenn mehr als eine im lokalen Mesh vorhanden ist. Dann habe ich noch die Gewichtung der Mesh Router geändert. Bisher bekam ein VPN Router das Gewicht von 2 und ein einfacher Mesh Router das Gewicht von 1. Wenn nun per Mesh on LAN/WAN mehre Hoods ermittelt worden sind gewinnt immer die Hood mit dem größten Gewicht. Jetzt hat ein VPN Router ein Gewicht von 20. Eine Beispiel Rechnung: Aktuelle Firmware 10 Router davon ist einer VPN Uplink. Alle anderen 9 Meshen nur über Mesh on LAN/WAN. Die Richtige Hood wäre in diesem Beispiel Oldenburg. Aktuell sind nach einem Sysupgrade alle Router in der Default Hood, da die Einstellungen beim Sysupgrade aus der site.conf überschrieben werden, dazu später mehr. Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 2 Hood Default 8 Der Meshknoten würde weiterhin die Default Hood auswählen. Wenn in der Zwischenzeit der Hoodselector auf dem VPN Router ausgeführt wird schaltet dieser immer im Wechsel zusätzlich noch Mesh on LAN/WAN immer ein und aus, diesem im Rhythmus des Cronjobs Meine Jetzige Testing Version: Kleiche Routerkonstellation Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 20 Hood Default 8 Jetzt wählt der MeshKnoten die Richtige Hood aus. Alle anderen Meshknoten werden nachziehen und nach einem einmaligen Durchlauf des hoodselectors in der gleichen Hood sein. Der VPN Router schaltet jetzt nicht mehr seine Mesh on LAN/WAN Verbindung ab. Ich denke bis VXLAN im Kernel uns zur Verfügung steht und sich unser Meshing Problem in Luft auflöst ist dieses eine sehr praxisnahe praktikable Lösung. Zusätzlich habe ich den Hoodselctor update fest eingebaut. Bedeutet das auch nach einem sys upgrade der Router in seiner alten Hood wieder startet. Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sys upgrade erhalten und wird nicht verändert. Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood. Zusätzlich steht nun nach dem Login auf dem Router auch die Ausgewählte Hood zur Verfügung. Schaut es euch einfach mal an. Ich hoffe das hilft die Stabilität unseres Netzes zu Verbessen Ich habe bzw bin gerade noch dabei einen Cooperative Locator zu bauen, der es ermöglichen soll die Position an Hand der umliegenden Router zu ermitteln. Eine erste noch nicht fertige, aber lauffähige Version ist in der Testing enthalten. Dieses Paket baue ich in einem Git Submodule. Ich habe schon vor über einem Jahr eingebaut das die submodules beim gluon build mit ausgecheckt werden, um gleich die Frage zu beantworten ob das klappt. Den Code dazu findet ihr hier: https://git.ffnw.de/ffnw-firmware/cooplocator <https://git.ffnw.de/ffnw-firmware/cooplocator> Zukünftig kann der geolocator dann damit die Position anhand der umliegenden WLAN Netzwerke über openwifi.su und anhand der lokalen Mesh Knoten vor Ort ermitteln. Fragen? Wünsche? Anregungen? Gruß Johannes
Die Gewichtung scheint mir recht willkürlich und nicht durchdacht zu sein. Warum haben reine Mesh-Router überhaupt ein Gewicht? Sie bestimmen niemals die Hoodauswahl sondern koppeln sich selber irgendwo an. Problem sind doch nur konkurrierende VPN Router in unterschiedlichen Hoods. Vorschlag: Die VPN Router, die nach Gewicht in der falschen Hood sind, schalten MoW/MoL ab. Alle anderen lassen an. Die Meshwolke ist quasi sofort eindeutig migriert. Am 28.02.2017 09:09 schrieb "Johannes Rudolph via Dev" <dev@lists.ffnw.de>:
Moin zusammen,
ich habe gerade eine neue Testing gebaut. Ihr findet sie hier:
Meine Änderungen zum Aktuellen stable findet ihr hier:
https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703
Download:
https://firmware.ffnw.de/20170227_testing/
Meine Änderungen / Anpassungen / Ergänzungen:
Hoodselector:
Ich habe folgendes umgebaut, was für die Praxis mir aktuell deutlich sin voller erscheint:
Wenn ein Router ein VPN Router ist und eingetragene Koordinaten hat, wird nich überprüft ob es einen Mesh Konflikt per Mesh on LAN/WAN gibt. Sicherlich kann es hierdurch zu Hoodkurzschlüssen kommen, allerdings passiert das aktuell bei Firmware updates sehr oft und ich und Stefan sind den ganzen Tag dabei diese Hoodkurzschlüsse auf den Supernodes zu trennen. Dadurch das der VPN Router dieses nicht mehr prüft haben die MeshKnoten um ihn herum es einfacher die richtige Hood zu finden, wenn mehr als eine im lokalen Mesh vorhanden ist.
Dann habe ich noch die Gewichtung der Mesh Router geändert. Bisher bekam ein VPN Router das Gewicht von 2 und ein einfacher Mesh Router das Gewicht von 1. Wenn nun per Mesh on LAN/WAN mehre Hoods ermittelt worden sind gewinnt immer die Hood mit dem größten Gewicht. Jetzt hat ein VPN Router ein Gewicht von 20.
Eine Beispiel Rechnung:
Aktuelle Firmware
10 Router davon ist einer VPN Uplink. Alle anderen 9 Meshen nur über Mesh on LAN/WAN. Die Richtige Hood wäre in diesem Beispiel Oldenburg. Aktuell sind nach einem Sysupgrade alle Router in der Default Hood, da die Einstellungen beim Sysupgrade aus der site.conf überschrieben werden, dazu später mehr. Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 2 Hood Default 8 Der Meshknoten würde weiterhin die Default Hood auswählen. Wenn in der Zwischenzeit der Hoodselector auf dem VPN Router ausgeführt wird schaltet dieser immer im Wechsel zusätzlich noch Mesh on LAN/WAN immer ein und aus, diesem im Rhythmus des Cronjobs
Meine Jetzige Testing Version:
Kleiche Routerkonstellation Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 20 Hood Default 8 Jetzt wählt der MeshKnoten die Richtige Hood aus. Alle anderen Meshknoten werden nachziehen und nach einem einmaligen Durchlauf des hoodselectors in der gleichen Hood sein. Der VPN Router schaltet jetzt nicht mehr seine Mesh on LAN/WAN Verbindung ab.
Ich denke bis VXLAN im Kernel uns zur Verfügung steht und sich unser Meshing Problem in Luft auflöst ist dieses eine sehr praxisnahe praktikable Lösung.
Zusätzlich habe ich den Hoodselctor update fest eingebaut. Bedeutet das auch nach einem sys upgrade der Router in seiner alten Hood wieder startet. Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sys upgrade erhalten und wird nicht verändert.
Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood.
Zusätzlich steht nun nach dem Login auf dem Router auch die Ausgewählte Hood zur Verfügung.
Schaut es euch einfach mal an. Ich hoffe das hilft die Stabilität unseres Netzes zu Verbessen
Ich habe bzw bin gerade noch dabei einen Cooperative Locator zu bauen, der es ermöglichen soll die Position an Hand der umliegenden Router zu ermitteln. Eine erste noch nicht fertige, aber lauffähige Version ist in der Testing enthalten. Dieses Paket baue ich in einem Git Submodule. Ich habe schon vor über einem Jahr eingebaut das die submodules beim gluon build mit ausgecheckt werden, um gleich die Frage zu beantworten ob das klappt. Den Code dazu findet ihr hier: https://git.ffnw.de/ ffnw-firmware/cooplocator Zukünftig kann der geolocator dann damit die Position anhand der umliegenden WLAN Netzwerke über openwifi.su und anhand der lokalen Mesh Knoten vor Ort ermitteln.
Fragen? Wünsche? Anregungen?
Gruß
Johannes
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin, ich gebe hiet Johannes er recht. Wir müssen eine Lösung finden, bei der nicht immer MoL und MoW abgestellt werden, denn das nervt bei großen Installationen auf dauer. Ich halte die Variante, die Gewichtung bei Mesh Routern, miteinzubeziehen für richtig. Aktuell kommt es vor, dass aufgrund fehlerhafter Mesh Router, eine komplette Installation in einer falschen Hood landet. Am 28. Februar 2017 10:56:39 AM schrieb Simon Kurka via Dev <dev@lists.ffnw.de>:
Die Gewichtung scheint mir recht willkürlich und nicht durchdacht zu sein.
Warum haben reine Mesh-Router überhaupt ein Gewicht? Sie bestimmen niemals die Hoodauswahl sondern koppeln sich selber irgendwo an.
Problem sind doch nur konkurrierende VPN Router in unterschiedlichen Hoods.
Vorschlag: Die VPN Router, die nach Gewicht in der falschen Hood sind, schalten MoW/MoL ab. Alle anderen lassen an. Die Meshwolke ist quasi sofort eindeutig migriert.
Am 28.02.2017 09:09 schrieb "Johannes Rudolph via Dev" <dev@lists.ffnw.de>:
Moin zusammen,
ich habe gerade eine neue Testing gebaut. Ihr findet sie hier:
Meine Änderungen zum Aktuellen stable findet ihr hier:
https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703
Download:
https://firmware.ffnw.de/20170227_testing/
Meine Änderungen / Anpassungen / Ergänzungen:
Hoodselector:
Ich habe folgendes umgebaut, was für die Praxis mir aktuell deutlich sin voller erscheint:
Wenn ein Router ein VPN Router ist und eingetragene Koordinaten hat, wird nich überprüft ob es einen Mesh Konflikt per Mesh on LAN/WAN gibt. Sicherlich kann es hierdurch zu Hoodkurzschlüssen kommen, allerdings passiert das aktuell bei Firmware updates sehr oft und ich und Stefan sind den ganzen Tag dabei diese Hoodkurzschlüsse auf den Supernodes zu trennen. Dadurch das der VPN Router dieses nicht mehr prüft haben die MeshKnoten um ihn herum es einfacher die richtige Hood zu finden, wenn mehr als eine im lokalen Mesh vorhanden ist.
Dann habe ich noch die Gewichtung der Mesh Router geändert. Bisher bekam ein VPN Router das Gewicht von 2 und ein einfacher Mesh Router das Gewicht von 1. Wenn nun per Mesh on LAN/WAN mehre Hoods ermittelt worden sind gewinnt immer die Hood mit dem größten Gewicht. Jetzt hat ein VPN Router ein Gewicht von 20.
Eine Beispiel Rechnung:
Aktuelle Firmware
10 Router davon ist einer VPN Uplink. Alle anderen 9 Meshen nur über Mesh on LAN/WAN. Die Richtige Hood wäre in diesem Beispiel Oldenburg. Aktuell sind nach einem Sysupgrade alle Router in der Default Hood, da die Einstellungen beim Sysupgrade aus der site.conf überschrieben werden, dazu später mehr. Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 2 Hood Default 8 Der Meshknoten würde weiterhin die Default Hood auswählen. Wenn in der Zwischenzeit der Hoodselector auf dem VPN Router ausgeführt wird schaltet dieser immer im Wechsel zusätzlich noch Mesh on LAN/WAN immer ein und aus, diesem im Rhythmus des Cronjobs
Meine Jetzige Testing Version:
Kleiche Routerkonstellation Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 20 Hood Default 8 Jetzt wählt der MeshKnoten die Richtige Hood aus. Alle anderen Meshknoten werden nachziehen und nach einem einmaligen Durchlauf des hoodselectors in der gleichen Hood sein. Der VPN Router schaltet jetzt nicht mehr seine Mesh on LAN/WAN Verbindung ab.
Ich denke bis VXLAN im Kernel uns zur Verfügung steht und sich unser Meshing Problem in Luft auflöst ist dieses eine sehr praxisnahe praktikable Lösung.
Zusätzlich habe ich den Hoodselctor update fest eingebaut. Bedeutet das auch nach einem sys upgrade der Router in seiner alten Hood wieder startet. Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sys upgrade erhalten und wird nicht verändert.
Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood.
Zusätzlich steht nun nach dem Login auf dem Router auch die Ausgewählte Hood zur Verfügung.
Schaut es euch einfach mal an. Ich hoffe das hilft die Stabilität unseres Netzes zu Verbessen
Ich habe bzw bin gerade noch dabei einen Cooperative Locator zu bauen, der es ermöglichen soll die Position an Hand der umliegenden Router zu ermitteln. Eine erste noch nicht fertige, aber lauffähige Version ist in der Testing enthalten. Dieses Paket baue ich in einem Git Submodule. Ich habe schon vor über einem Jahr eingebaut das die submodules beim gluon build mit ausgecheckt werden, um gleich die Frage zu beantworten ob das klappt. Den Code dazu findet ihr hier: https://git.ffnw.de/ ffnw-firmware/cooplocator Zukünftig kann der geolocator dann damit die Position anhand der umliegenden WLAN Netzwerke über openwifi.su und anhand der lokalen Mesh Knoten vor Ort ermitteln.
Fragen? Wünsche? Anregungen?
Gruß
Johannes
_______________________________________________ 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
Moin Also mein Ziel dieser Lösung ist es nicht eine Dauerlösung zu schaffen sondern viel mehr eine praktikable Lösung zu finden. Damit wir aktuell diese MASSIVEN Probleme nicht mehr haben. Nach den letzten updates mussten wir jeweils händisch eingreifen um Wittmund wieder in die richtige Hold zu bringen und ich denke der eine oder andere mit "größeren" Offloader Installationen hatte dieselben Probleme. Wenn ich da mal Richtung Lohne Osnabrück und Bad Iburg schaue. Aktuell ist es mehr ein Workarround, damit wir weiter machen können mit unseren Hoods, da sind wir auf einem guten Weg gerade. Gruß Johannes Von meinem iPhone gesendet
Am 28.02.2017 um 11:10 schrieb Stefan Dunkel via Dev <dev@lists.ffnw.de>:
Moin,
ich gebe hiet Johannes er recht.
Wir müssen eine Lösung finden, bei der nicht immer MoL und MoW abgestellt werden, denn das nervt bei großen Installationen auf dauer.
Ich halte die Variante, die Gewichtung bei Mesh Routern, miteinzubeziehen für richtig.
Aktuell kommt es vor, dass aufgrund fehlerhafter Mesh Router, eine komplette Installation in einer falschen Hood landet.
Am 28. Februar 2017 10:56:39 AM schrieb Simon Kurka via Dev <dev@lists.ffnw.de>:
Die Gewichtung scheint mir recht willkürlich und nicht durchdacht zu sein.
Warum haben reine Mesh-Router überhaupt ein Gewicht? Sie bestimmen niemals die Hoodauswahl sondern koppeln sich selber irgendwo an.
Problem sind doch nur konkurrierende VPN Router in unterschiedlichen Hoods.
Vorschlag: Die VPN Router, die nach Gewicht in der falschen Hood sind, schalten MoW/MoL ab. Alle anderen lassen an. Die Meshwolke ist quasi sofort eindeutig migriert.
Am 28.02.2017 09:09 schrieb "Johannes Rudolph via Dev" <dev@lists.ffnw.de>:
Moin zusammen,
ich habe gerade eine neue Testing gebaut. Ihr findet sie hier:
Meine Änderungen zum Aktuellen stable findet ihr hier:
https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703
Download:
https://firmware.ffnw.de/20170227_testing/
Meine Änderungen / Anpassungen / Ergänzungen:
Hoodselector:
Ich habe folgendes umgebaut, was für die Praxis mir aktuell deutlich sin voller erscheint:
Wenn ein Router ein VPN Router ist und eingetragene Koordinaten hat, wird nich überprüft ob es einen Mesh Konflikt per Mesh on LAN/WAN gibt. Sicherlich kann es hierdurch zu Hoodkurzschlüssen kommen, allerdings passiert das aktuell bei Firmware updates sehr oft und ich und Stefan sind den ganzen Tag dabei diese Hoodkurzschlüsse auf den Supernodes zu trennen. Dadurch das der VPN Router dieses nicht mehr prüft haben die MeshKnoten um ihn herum es einfacher die richtige Hood zu finden, wenn mehr als eine im lokalen Mesh vorhanden ist.
Dann habe ich noch die Gewichtung der Mesh Router geändert. Bisher bekam ein VPN Router das Gewicht von 2 und ein einfacher Mesh Router das Gewicht von 1. Wenn nun per Mesh on LAN/WAN mehre Hoods ermittelt worden sind gewinnt immer die Hood mit dem größten Gewicht. Jetzt hat ein VPN Router ein Gewicht von 20.
Eine Beispiel Rechnung:
Aktuelle Firmware
10 Router davon ist einer VPN Uplink. Alle anderen 9 Meshen nur über Mesh on LAN/WAN. Die Richtige Hood wäre in diesem Beispiel Oldenburg. Aktuell sind nach einem Sysupgrade alle Router in der Default Hood, da die Einstellungen beim Sysupgrade aus der site.conf überschrieben werden, dazu später mehr. Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 2 Hood Default 8 Der Meshknoten würde weiterhin die Default Hood auswählen. Wenn in der Zwischenzeit der Hoodselector auf dem VPN Router ausgeführt wird schaltet dieser immer im Wechsel zusätzlich noch Mesh on LAN/WAN immer ein und aus, diesem im Rhythmus des Cronjobs
Meine Jetzige Testing Version:
Kleiche Routerkonstellation
Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 20 Hood Default 8 Jetzt wählt der MeshKnoten die Richtige Hood aus. Alle anderen Meshknoten werden nachziehen und nach einem einmaligen Durchlauf des hoodselectors in der gleichen Hood sein. Der VPN Router schaltet jetzt nicht mehr seine Mesh on LAN/WAN Verbindung ab.
Ich denke bis VXLAN im Kernel uns zur Verfügung steht und sich unser Meshing Problem in Luft auflöst ist dieses eine sehr praxisnahe praktikable Lösung.
Zusätzlich habe ich den Hoodselctor update fest eingebaut. Bedeutet das auch nach einem sys upgrade der Router in seiner alten Hood wieder startet. Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sys upgrade erhalten und wird nicht verändert.
Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood.
Zusätzlich steht nun nach dem Login auf dem Router auch die Ausgewählte Hood zur Verfügung.
Schaut es euch einfach mal an. Ich hoffe das hilft die Stabilität unseres Netzes zu Verbessen
Ich habe bzw bin gerade noch dabei einen Cooperative Locator zu bauen, der es ermöglichen soll die Position an Hand der umliegenden Router zu ermitteln. Eine erste noch nicht fertige, aber lauffähige Version ist in der Testing enthalten. Dieses Paket baue ich in einem Git Submodule. Ich habe schon vor über einem Jahr eingebaut das die submodules beim gluon build mit ausgecheckt werden, um gleich die Frage zu beantworten ob das klappt. Den Code dazu findet ihr hier: https://git.ffnw.de/ffnw-firmware/cooplocator Zukünftig kann der geolocator dann damit die Position anhand der umliegenden WLAN Netzwerke über openwifi.su und anhand der lokalen Mesh Knoten vor Ort ermitteln.
Fragen? Wünsche? Anregungen?
Gruß
Johannes
_______________________________________________ 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
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Nochmal die Frage: Warum haben Mesh-Router ein Gewicht? Sie bestimmen die zu wählende Hood nicht und schwenken mit einem VPN Router quasi sofort um. Die Erhöhung der Anzahl möglicher Mesh-Router bis das gleiche Problem wieder auftritt, das kann doch nicht euer ernst sein?! Am 28.02.2017 14:25 schrieb "Johannes Rudolph via Dev" <dev@lists.ffnw.de>:
Moin
Also mein Ziel dieser Lösung ist es nicht eine Dauerlösung zu schaffen sondern viel mehr eine praktikable Lösung zu finden. Damit wir aktuell diese MASSIVEN Probleme nicht mehr haben.
Nach den letzten updates mussten wir jeweils händisch eingreifen um Wittmund wieder in die richtige Hold zu bringen und ich denke der eine oder andere mit "größeren" Offloader Installationen hatte dieselben Probleme. Wenn ich da mal Richtung Lohne Osnabrück und Bad Iburg schaue.
Aktuell ist es mehr ein Workarround, damit wir weiter machen können mit unseren Hoods, da sind wir auf einem guten Weg gerade.
Gruß Johannes
Von meinem iPhone gesendet
Am 28.02.2017 um 11:10 schrieb Stefan Dunkel via Dev <dev@lists.ffnw.de>:
Moin,
ich gebe hiet Johannes er recht.
Wir müssen eine Lösung finden, bei der nicht immer MoL und MoW abgestellt werden, denn das nervt bei großen Installationen auf dauer.
Ich halte die Variante, die Gewichtung bei Mesh Routern, miteinzubeziehen für richtig.
Aktuell kommt es vor, dass aufgrund fehlerhafter Mesh Router, eine komplette Installation in einer falschen Hood landet.
Am 28. Februar 2017 10:56:39 AM schrieb Simon Kurka via Dev < dev@lists.ffnw.de>:
Die Gewichtung scheint mir recht willkürlich und nicht durchdacht zu sein.
Warum haben reine Mesh-Router überhaupt ein Gewicht? Sie bestimmen niemals die Hoodauswahl sondern koppeln sich selber irgendwo an.
Problem sind doch nur konkurrierende VPN Router in unterschiedlichen Hoods.
Vorschlag: Die VPN Router, die nach Gewicht in der falschen Hood sind, schalten MoW/MoL ab. Alle anderen lassen an. Die Meshwolke ist quasi sofort eindeutig migriert.
Am 28.02.2017 09:09 schrieb "Johannes Rudolph via Dev" <dev@lists.ffnw.de
:
Moin zusammen,
ich habe gerade eine neue Testing gebaut. Ihr findet sie hier:
Meine Änderungen zum Aktuellen stable findet ihr hier:
https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703
Download:
https://firmware.ffnw.de/20170227_testing/
Meine Änderungen / Anpassungen / Ergänzungen:
Hoodselector:
Ich habe folgendes umgebaut, was für die Praxis mir aktuell deutlich sin voller erscheint:
Wenn ein Router ein VPN Router ist und eingetragene Koordinaten hat, wird nich überprüft ob es einen Mesh Konflikt per Mesh on LAN/WAN gibt. Sicherlich kann es hierdurch zu Hoodkurzschlüssen kommen, allerdings passiert das aktuell bei Firmware updates sehr oft und ich und Stefan sind den ganzen Tag dabei diese Hoodkurzschlüsse auf den Supernodes zu trennen. Dadurch das der VPN Router dieses nicht mehr prüft haben die MeshKnoten um ihn herum es einfacher die richtige Hood zu finden, wenn mehr als eine im lokalen Mesh vorhanden ist.
Dann habe ich noch die Gewichtung der Mesh Router geändert. Bisher bekam ein VPN Router das Gewicht von 2 und ein einfacher Mesh Router das Gewicht von 1. Wenn nun per Mesh on LAN/WAN mehre Hoods ermittelt worden sind gewinnt immer die Hood mit dem größten Gewicht. Jetzt hat ein VPN Router ein Gewicht von 20.
Eine Beispiel Rechnung:
Aktuelle Firmware
10 Router davon ist einer VPN Uplink. Alle anderen 9 Meshen nur über Mesh on LAN/WAN. Die Richtige Hood wäre in diesem Beispiel Oldenburg. Aktuell sind nach einem Sysupgrade alle Router in der Default Hood, da die Einstellungen beim Sysupgrade aus der site.conf überschrieben werden, dazu später mehr. Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 2 Hood Default 8 Der Meshknoten würde weiterhin die Default Hood auswählen. Wenn in der Zwischenzeit der Hoodselector auf dem VPN Router ausgeführt wird schaltet dieser immer im Wechsel zusätzlich noch Mesh on LAN/WAN immer ein und aus, diesem im Rhythmus des Cronjobs
Meine Jetzige Testing Version:
Kleiche Routerkonstellation Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 20 Hood Default 8 Jetzt wählt der MeshKnoten die Richtige Hood aus. Alle anderen Meshknoten werden nachziehen und nach einem einmaligen Durchlauf des hoodselectors in der gleichen Hood sein. Der VPN Router schaltet jetzt nicht mehr seine Mesh on LAN/WAN Verbindung ab.
Ich denke bis VXLAN im Kernel uns zur Verfügung steht und sich unser Meshing Problem in Luft auflöst ist dieses eine sehr praxisnahe praktikable Lösung.
Zusätzlich habe ich den Hoodselctor update fest eingebaut. Bedeutet das auch nach einem sys upgrade der Router in seiner alten Hood wieder startet. Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sys upgrade erhalten und wird nicht verändert.
Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood.
Zusätzlich steht nun nach dem Login auf dem Router auch die Ausgewählte Hood zur Verfügung.
Schaut es euch einfach mal an. Ich hoffe das hilft die Stabilität unseres Netzes zu Verbessen
Ich habe bzw bin gerade noch dabei einen Cooperative Locator zu bauen, der es ermöglichen soll die Position an Hand der umliegenden Router zu ermitteln. Eine erste noch nicht fertige, aber lauffähige Version ist in der Testing enthalten. Dieses Paket baue ich in einem Git Submodule. Ich habe schon vor über einem Jahr eingebaut das die submodules beim gluon build mit ausgecheckt werden, um gleich die Frage zu beantworten ob das klappt. Den Code dazu findet ihr hier: https://git.ffnw.de/ffnw -firmware/cooplocator Zukünftig kann der geolocator dann damit die Position anhand der umliegenden WLAN Netzwerke über openwifi.su und anhand der lokalen Mesh Knoten vor Ort ermitteln.
Fragen? Wünsche? Anregungen?
Gruß
Johannes
_______________________________________________ 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
_______________________________________________ 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
On 02/28/17 10:56, Simon Kurka via Dev wrote:
Die Gewichtung scheint mir recht willkürlich und nicht durchdacht zu sein.
Warum haben reine Mesh-Router überhaupt ein Gewicht? Sie bestimmen niemals die Hoodauswahl sondern koppeln sich selber irgendwo an.
Das ist in der jetzigen stabile noch enthalten und basiert auf einem gedanklichen Fehler von mir.
Problem sind doch nur konkurrierende VPN Router in unterschiedlichen Hoods.
und das konfigurieren in einer offline Wolke unter reinen mesh Routern.
Vorschlag: Die VPN Router, die nach Gewicht in der falschen Hood sind, schalten MoW/MoL ab. Alle anderen lassen an. Die Meshwolke ist quasi sofort eindeutig migriert.
Genau so, hatte ich es geplant gehabt. Zumindest für den Umgang mit den VPNroutern. Grundsätzlich muss man hier unter scheiden zwischen meshRoutern und VPNroutern. Eine Gewichtung sollte bei beiden unter sich zu tragen kommen. Spricht ein neuer router wird an eine offline wolke angeschlossen, Alle anderen Router haben bsp. die OS hood der neue aber die Lohne hood da mehr router in der OS hood sind wechselt der aus lohne auch in die OS hood. Im falle einer meshwolke mit Gateway wählen die mesh Router aus einer liste von VPN neigbours die VPN Router aus einer hood die am häufigsten vorkommen werden gewählt. Das Problem bei der Lösung in der stable und auch in der testing von Johannes das nicht zwischen vpn und mesh unterschieden wurde. Was dazu führt das es bei größerer Skalierung trotzdem knallt. Die oben aufgeführte Lösung hab ich bei mir lokal bereits implementiert und benötigt nur ein paar Zeilen Änerung in einer einzelnen Funktion. Schöne Grüße Tarek
Hi,
ich habe gerade eine neue Testing gebaut. Ihr findet sie hier:
Danke dir :)
Meine Änderungen zum Aktuellen stable findet ihr hier:
https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703 <https://git.ffnw.de/ffnw-firmware/packages/tree/johannes/201703>
Kommentare zum code folgen in den einzeln commits.
Download:
https://firmware.ffnw.de/20170227_testing/
Meine Änderungen / Anpassungen / Ergänzungen:
Hoodselector:
Ich habe folgendes umgebaut, was für die Praxis mir aktuell deutlich sin voller erscheint:
Wenn ein Router ein VPN Router ist und eingetragene Koordinaten hat, wird nich überprüft ob es einen Mesh Konflikt per Mesh on LAN/WAN gibt. Sicherlich kann es hierdurch zu Hoodkurzschlüssen kommen, allerdings passiert das aktuell bei Firmware updates sehr oft und ich und Stefan sind den ganzen Tag dabei diese Hoodkurzschlüsse auf den Supernodes zu trennen. Dadurch das der VPN Router dieses nicht mehr prüft haben die MeshKnoten um ihn herum es einfacher die richtige Hood zu finden, wenn mehr als eine im lokalen Mesh vorhanden ist.
Ich bin dieser Umstellung eher skeptisch gegenüber gestimmt, da der VPNrouter das "tor" zum restlichen Netz einer hood stellt sollte dieser meiner Meinung nach das mol oder mow bei einem Konflikt abschalten. Dem abschnitt oben zu folge ist das ganze molwm in Konfliktsituationen raus geflogen?
Dann habe ich noch die Gewichtung der Mesh Router geändert. Bisher bekam ein VPN Router das Gewicht von 2 und ein einfacher Mesh Router das Gewicht von 1. Wenn nun per Mesh on LAN/WAN mehre Hoods ermittelt worden sind gewinnt immer die Hood mit dem größten Gewicht. Jetzt hat ein VPN Router ein Gewicht von 20.
Eine Beispiel Rechnung:
Aktuelle Firmware
10 Router davon ist einer VPN Uplink. Alle anderen 9 Meshen nur über Mesh on LAN/WAN. Die Richtige Hood wäre in diesem Beispiel Oldenburg. Aktuell sind nach einem Sysupgrade alle Router in der Default Hood, da die Einstellungen beim Sysupgrade aus der site.conf überschrieben werden, dazu später mehr. Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 2 Hood Default 8 Der Meshknoten würde weiterhin die Default Hood auswählen. Wenn in der Zwischenzeit der Hoodselector auf dem VPN Router ausgeführt wird schaltet dieser immer im Wechsel zusätzlich noch Mesh on LAN/WAN immer ein und aus, diesem im Rhythmus des Cronjobs
Meine Jetzige Testing Version:
Kleiche Routerkonstellation
Wenn nun der Hoodselector auf einem der Mesh Knoten ausgeführt wird ergibt sich folgende Gewichtung Hood Oldenburg 20 Hood Default 8 Jetzt wählt der MeshKnoten die Richtige Hood aus. Alle anderen Meshknoten werden nachziehen und nach einem einmaligen Durchlauf des hoodselectors in der gleichen Hood sein. Der VPN Router schaltet jetzt nicht mehr seine Mesh on LAN/WAN Verbindung ab.
Das löst das Grundproblem nicht, was dir sicherlich bewusst ist. Fürst erste würde das für Mesh Netze <20 mesh Router in einem lan Konstrukt funktionieren. Darüber hinaus hätten wir das identische Problem wie jetzt.
Ich denke bis VXLAN im Kernel uns zur Verfügung steht und sich unser Meshing Problem in Luft auflöst ist dieses eine sehr praxisnahe praktikable Lösung.
VXLAN wird noch einige zeit dauern, ich gehe davon aus das es evtl. zum ende des Jahres oder Anfang nächsten Jahres kommt. Der Kernel Support fehlt noch sowie die Implementierung in netifid.
Zusätzlich habe ich den Hoodselctor update fest eingebaut. Bedeutet das auch nach einem sysupgrade der Router in seiner alten Hood wieder startet.
Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sysupgrade erhalten und wird nicht verändert.
Sehr schön :) Dazu bestehe auch ein paar issues. commenst gibst dann im code wenn nötig.
Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood.
Hier bin ich mir nicht sicher wie man da am besten ran gehen sollte. Sicherlich ist diese Variante eine Möglichkeit, die schnell umgesetzt ist. Die bessere Variante wäre das package gluon-mesh-vpn-fastd zu clonen und die siteconf Abhängigkeit raus zu schmeißen. Das wäre der schönere weg und könnte dann mit samt der hoodselectors in gluon aufgenommen werden. Nach den obigen beschreibenden vorgehen wird eine Aufnahme 100% abgelehnt.
Zusätzlich steht nun nach dem Login auf dem Router auch die Ausgewählte Hood zur Verfügung.
Hm, das erfordert wahrscheinlich ein kontinuierliches neu schreiben des Banners? Ich schau mir den Code dazu mal an. Bin aber der Meinung das so eine Änderung nicht zwingend notwendig ist. Da dies nicht wirklich nötig ist.
Schaut es euch einfach mal an. Ich hoffe das hilft die Stabilität unseres Netzes zu Verbessen
jedenfall ganz herzlichen dank schon mal für deine Arbeit, Kommentare dazu folgen die tage im Code.
Ich habe bzw bin gerade noch dabei einen Cooperative Locator zu bauen, der es ermöglichen soll die Position an Hand der umliegenden Router zu ermitteln. Eine erste noch nicht fertige, aber lauffähige Version ist in der Testing enthalten. Dieses Paket baue ich in einem Git Submodule. Ich habe schon vor über einem Jahr eingebaut das die submodules beim gluon build mit ausgecheckt werden, um gleich die Frage zu beantworten ob das klappt. Den Code dazu findet ihr hier: https://git.ffnw.de/ffnw-firmware/cooplocator Zukünftig kann der geolocator dann damit die Position anhand der umliegenden WLAN Netzwerke über openwifi.su und anhand der lokalen Mesh Knoten vor Ort ermitteln.
Klinkt interessant da schaue ich mal mit rein.
Fragen? Wünsche? Anregungen?
Der Cooperative Locator: Wozu soll dar dann genau dienen? Schöne Grüße Tarek P.S. Deine mailer ist falsch konfiguriert. Die Mails sind alle doppelt, wovon eine Version in einem falschen ascii Format ist. Zudem sind die mails beim zitieren Einzeller. Scheinbar sind die Zeilen Umbrüche kaputt. Sobald ich den text dann zum zitieren passend formatieren will werden z.B. zwei newlines für eine "enter" gesetzt. Dazu kommst das urls alle doppelt hintereinander eingefügt werden. Ganz merkwürdig. Da du aber von einer *@ffnw.de mail sendest ist meine Vermutung das dein mail Programm die Mails kaputt macht. Magst du deinen Mailprogramm passend Konfigurieren?
Hi,
Dafür speichert der Hoodselector nun in der Datei /etc/config/hoodselector seine aktuell ausgewählte Hood ab. Diese Datei bleibt beim sysupgrade erhalten und wird nicht verändert.
Sehr schön :) Dazu bestehe auch ein paar issues. commenst gibst dann im code wenn nötig.
Nach dem Sysupgrade laufen einige Upgrade Skripte. Nach dem Durchlauf des Skriptes das nun standardmäßig die fastd Config anhand der site.conf überschreibt, läuft ein weiteres Skript, dass die richtige fastd Config für die Hood anhand der gespeicherten Hood aus dem Hoodfile neu schreibt. Nun verbindet sich der Router nach dem Sysupgrade wieder mit der richtigen Hood auf anhieb und landet nicht mehr standardmäßig in der Default Hood.
Hier bin ich mir nicht sicher wie man da am besten ran gehen sollte. Sicherlich ist diese Variante eine Möglichkeit, die schnell umgesetzt ist. Die bessere Variante wäre das package gluon-mesh-vpn-fastd zu clonen und die siteconf Abhängigkeit raus zu schmeißen. Das wäre der schönere weg und könnte dann mit samt der hoodselectors in gluon aufgenommen werden. Nach den obigen beschreibenden vorgehen wird eine Aufnahme 100% abgelehnt.
Hm, ich will meine Äußerung hier noch mal zurück ziehen. Das package müsste so flexibel gestaltet werden das meiner Meinung nach zu compile zeit bereits die Abhängigkeit zur site.conf aufgelöst werden muss oder nicht. um ein nutzen ohne hoodselector trotzdem zu gewährleisten. Die andre Variante so wie sie oben von Johannes geschrieben wurde wäre eben zur Laufzeit. Das geht auch ist meiner Meinung nach aber unschön. Streng packages basiert betrachtet aber korrekt. Wäre aber eine Änderung die man in den Master übernehmen könnte. vg Tarek
Moin
Klinkt interessant da schaue ich mal mit rein.
Fragen? Wünsche? Anregungen?
Der Cooperative Locator: Wozu soll dar dann genau dienen?
Er soll mittels Cooperative Locationing es möglich machen ähnlich dem lwtrace Programm eine Koordinate für den Router zu ermitteln. Dazu fragt er die umliegenden Router im Mesh ab und versucht damit eine eigne Position zu ermitteln. Aktuell ist die Implementierung noch nicht abgeschlossen. Aber eine Position kann man schon ermitteln. Ich möchte noch eine Gewichtung einbauen. Positionsinformationen von WLAN Mesh Node sind stärker zu betrachten, als die von Mesh On LAN/WAN Nodes, da letzte über das Kabel auch ganz schön weit Weg sein können, wobei WLAN Mesh Router hingegeben sich ind er Regel in einem begrenzten Umkreis un den eigentlichen Node sich befinden. Zusammen mit lwtrace könnte man so die position verbessern, ggf auch Prüfen ob das sinnvoll ist. Diese Überlegung wie man mit den beiden ermittelten Positionen arbeiten kann ist allerdings noch nicht abgeschlossen und ich bin da für neue Ideen offen. Gruß Johannes
participants (4)
-
Jan-Tarek Butt -
Johannes Rudolph -
Simon Kurka -
Stefan Dunkel