Hallo zusammen,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 1.2 * Gluon-Version: v2016.1.x * Commit ID: ee597c66769a455d38467192598813e7f8411cfd * Download: https://firmware.ffnw.de/1.2
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/ee597c...ee597c
Folgende Comunnity spezifischen Änderungen gab es: package repo: * logic Fehler im configmode wurden behoben Das Dropdown menu hat, bei wiederholten ausführen des configModes seinen zustand nicht wiederhergestellt. Das setzen zweier uci Parameter ist durch einen Typen Fehler nie zu Stande gekommen.
* Client seitige Javascript map im configeMode Es wird nun vom Router aus via Javascript auf den Client eine OSM Karte geladen, sofern der Client über eine Internet Verbindung verfügt. Um das selektieren von statischen Geo Koordinaten zu vereinfachen.
* hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48 Über respondd werden nun Informationen über die aktuell selektierte hood eines Routers verteilt.
* hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan / Wan Managemend Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes der einzelnen hoods.
* hoodselector: Der hoodselector gibt nun returncodes bei der Terminierung zurück.
* hoodselector: pid datei write Permission wird abgefangen
* hoodselector: Unbenutzte variablen wurden entfernt und das überlappen von Globalen variablen wurde behoben (zum Einsatz kam luacheck)
* hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS aber unterschiedlichen Port bestehen. #40 Das ermöglicht uns anstelle von folgenden zu schreiben: starwars0.sn.ffnw.de 1001 starwars1.sn.ffnw.de 1010 starwars1.sn.ffnw.de 1011
Lediglich: starwars.sn.ffnw.de 1001 starwars.sn.ffnw.de 1010 starwars.sn.ffnw.de 1011
Das reduziert somit die ganzen DNS Einträge.
* hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN Interfaces die ein Gerät hat. #69
* hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec fortgesetzt. #70
* hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und können und über logread eingesehen werden. #36
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.1.1...v1...
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.1.1...v1...
Schöne Grüße Tarek
Hi,
Ich schreibe hier mal meine test Kommandos damit alle Leute die testen ungefähr wissen was getestet werden muss.
als aller erstes heißt es natürlich code lesen also die Änderungen, um zu schauen das da keine offensichtlichen Fehler sind.
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- logic Fehler im configmode wurden behoben Das Dropdown menu hat, bei wiederholten ausführen des configModes seinen zustand nicht wiederhergestellt. Das setzen zweier uci Parameter ist durch einen Typen Fehler nie zu Stande gekommen.
Das kann man testen in dem man den Router mehrfach hintereinander in den configMode versetzt und die Koordinaten Einstellungen alle einmal durch testet. Zwischendurch immer per ssh schauen ob die Änderungen in der /etc/config/gluon-node-info korrekt eingetragen wurden und ob der zuvor gesetzten Zustände in der Web GUI wieder dargestellt werden.
- Client seitige Javascript map im configeMode Es wird nun vom Router aus via Javascript auf den Client eine OSM Karte geladen, sofern der Client über eine Internet Verbindung verfügt. Um das selektieren von statischen Geo Koordinaten zu vereinfachen.
Hie müssen die unterschiedlichen Koordinaten modi einmal durch selektiert werden Das ganze einmal als Client mit Internetverbindung und einmal ohne. Im falle ohne Internet sollte eine Karte erscheinen und der graue Balken sich nicht verändern.
- hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48 Über respondd werden nun Informationen über die aktuell selektierte hood eines Routers verteilt.
in der shell auf den router sollte mit folgendem Befehl folgendes json erscheinen
root@ffnwDevBox:~# gluon-neighbour-info -i bat0 -p 1001 -d ff02::2 -r hoodselector -t 0.5 {"hoodinfo":{"md5hash":"d213fb718df9f885ad152ee3f47160b5","vpnrouter":"false","hoodname": "default"},"selectedbssid":{"bssid":"02:CA:FF:EE:BA:BF"},"mesh":{"wan":true}}
- hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes der einzelnen hoods.
Das kann man testen indem man mehrere VPN Router aus unterschiedlichen hoods via mesh on lan und wan zusammen schließt. Die Router sollten gegenseitig beim aufrufen von hoodselector in der Konsole ausgeben das mesh on lan / wan deaktiviert wurde auf Grund von ungleichen md5hashes.
- hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.
Nach dem Aufrufen des hoodselectors kann man mit echo $? den Programm return code ausgeben 0 für erfolgreich und 1 für Misserfolg. Einen Misserfolg kann man herbei rufen indem man touch /var/run/hoodselector.pid ausführt und danach die o.g. Routine.
- hoodselector: pid datei write Permission wird abgefangen
joa das ist relativ trevial und kann einfachim code gelesen werden, da es auf den router nicht auftreten kann, da der hoodselector mit root rennt. Daher war diese eine reine Schönheitsänderung im Bezug auf die Router.
- hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)
Das ist im code einzusehen.
- hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40 Das ermöglicht uns anstelle von folgenden zu schreiben: starwars0.sn.ffnw.de 1001 starwars1.sn.ffnw.de 1010 starwars1.sn.ffnw.de 1011
Lediglich: starwars.sn.ffnw.de 1001 starwars.sn.ffnw.de 1010 starwars.sn.ffnw.de 1011 Das reduziert somit die ganzen DNS Einträge.
Das kann man testen indem man die hood.json anpasst und z.b. alle default2-6.ffnw.de Adressen auf default.ffnw.de ändert und die Ports alle unterschiedlich setzt. beim aufrufen des hoodselectors sollte die fastd conf angepasst werden. danach sollte in der /etc/config/fastd redundante DNS Einträge mit unterschiedlichen Ports stehen.
- hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN Interfaces die ein Gerät hat. #69
Das kann man testen in dem man zwei dualband Geräte hat und einer auf 2,4 und 5 GHz das mesh ausstrahlt. Der andere dualband Router mesh aber nur auf 5Ghz bei Aufruf des reinen mesh Routers sollte der mit mesh auf 5GHz sich mit den anderen Router verbinden und darüber online gehen. Einstellungen auf welchen Interfaces mesh ausgestrahlt werden soll kann man in configMode einstellen.
- hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec fortgesetzt. #70
aufrufen des hoodselctors im scanmode und sekunden zahlen.
- hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36
Das kann man ebenfalls erzielen indem man touch /var/run/hoodselector.pid aufruft und danach den hoodselechtor ein paar mal hintereinander ausführt. Dann einfach logread und Einträge begutachten.
Schöne Grüße Tarek
Hi,
Blogpost ist schon fertig. Brauch nach dem Umbiegen des Symlinkes nur noch veröffentlicht werden :)
VG
Stefan
Am 30.11.2016 um 20:00 schrieb Jan-Tarek Butt via Dev:
Hi,
Ich schreibe hier mal meine test Kommandos damit alle Leute die testen ungefähr wissen was getestet werden muss.
als aller erstes heißt es natürlich code lesen also die Änderungen, um zu schauen das da keine offensichtlichen Fehler sind.
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- logic Fehler im configmode wurden behoben Das Dropdown menu hat, bei wiederholten ausführen des configModes seinen zustand nicht wiederhergestellt. Das setzen zweier uci Parameter ist durch einen Typen Fehler nie zu Stande gekommen.
Das kann man testen in dem man den Router mehrfach hintereinander in den configMode versetzt und die Koordinaten Einstellungen alle einmal durch testet. Zwischendurch immer per ssh schauen ob die Änderungen in der /etc/config/gluon-node-info korrekt eingetragen wurden und ob der zuvor gesetzten Zustände in der Web GUI wieder dargestellt werden.
- Client seitige Javascript map im configeMode Es wird nun vom Router aus via Javascript auf den Client eine OSM Karte geladen, sofern der Client über eine Internet Verbindung verfügt. Um das selektieren von statischen Geo Koordinaten zu vereinfachen.
Hie müssen die unterschiedlichen Koordinaten modi einmal durch selektiert werden Das ganze einmal als Client mit Internetverbindung und einmal ohne. Im falle ohne Internet sollte eine Karte erscheinen und der graue Balken sich nicht verändern.
- hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48 Über respondd werden nun Informationen über die aktuell selektierte hood eines Routers verteilt.
in der shell auf den router sollte mit folgendem Befehl folgendes json erscheinen
root@ffnwDevBox:~# gluon-neighbour-info -i bat0 -p 1001 -d ff02::2 -r hoodselector -t 0.5 {"hoodinfo":{"md5hash":"d213fb718df9f885ad152ee3f47160b5","vpnrouter":"false","hoodname": "default"},"selectedbssid":{"bssid":"02:CA:FF:EE:BA:BF"},"mesh":{"wan":true}}
- hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes der einzelnen hoods.
Das kann man testen indem man mehrere VPN Router aus unterschiedlichen hoods via mesh on lan und wan zusammen schließt. Die Router sollten gegenseitig beim aufrufen von hoodselector in der Konsole ausgeben das mesh on lan / wan deaktiviert wurde auf Grund von ungleichen md5hashes.
- hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.
Nach dem Aufrufen des hoodselectors kann man mit echo $? den Programm return code ausgeben 0 für erfolgreich und 1 für Misserfolg. Einen Misserfolg kann man herbei rufen indem man touch /var/run/hoodselector.pid ausführt und danach die o.g. Routine.
- hoodselector: pid datei write Permission wird abgefangen
joa das ist relativ trevial und kann einfachim code gelesen werden, da es auf den router nicht auftreten kann, da der hoodselector mit root rennt. Daher war diese eine reine Schönheitsänderung im Bezug auf die Router.
- hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)
Das ist im code einzusehen.
- hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40 Das ermöglicht uns anstelle von folgenden zu schreiben: starwars0.sn.ffnw.de 1001 starwars1.sn.ffnw.de 1010 starwars1.sn.ffnw.de 1011
Lediglich: starwars.sn.ffnw.de 1001 starwars.sn.ffnw.de 1010 starwars.sn.ffnw.de 1011 Das reduziert somit die ganzen DNS Einträge.Das kann man testen indem man die hood.json anpasst und z.b. alle default2-6.ffnw.de Adressen auf default.ffnw.de ändert und die Ports alle unterschiedlich setzt. beim aufrufen des hoodselectors sollte die fastd conf angepasst werden. danach sollte in der /etc/config/fastd redundante DNS Einträge mit unterschiedlichen Ports stehen.
- hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN Interfaces die ein Gerät hat. #69
Das kann man testen in dem man zwei dualband Geräte hat und einer auf 2,4 und 5 GHz das mesh ausstrahlt. Der andere dualband Router mesh aber nur auf 5Ghz bei Aufruf des reinen mesh Routers sollte der mit mesh auf 5GHz sich mit den anderen Router verbinden und darüber online gehen. Einstellungen auf welchen Interfaces mesh ausgestrahlt werden soll kann man in configMode einstellen.
- hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec fortgesetzt. #70
aufrufen des hoodselctors im scanmode und sekunden zahlen.
- hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36
Das kann man ebenfalls erzielen indem man touch /var/run/hoodselector.pid aufruft und danach den hoodselechtor ein paar mal hintereinander ausführt. Dann einfach logread und Einträge begutachten.
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
mir ist noch ein Fehler bei einem 841 v9 aufgefallen:
"gluon-neighbour-info -i bat0 -p 1001 -d ff02::2 -r hoodselector -t 0.5" Error in sendto(): Permission denied
"hoodselector" VPN connection found. Position found. Set hood "lk-os" Hood set by VPN mode. Error in sendto(): Permission denied Interface mesh_lan enabled.
Am 01.12.2016 um 14:17 schrieb Stefan via Dev:
Hi,
Blogpost ist schon fertig. Brauch nach dem Umbiegen des Symlinkes nur noch veröffentlicht werden :)
VG
Stefan
Am 30.11.2016 um 20:00 schrieb Jan-Tarek Butt via Dev:
Hi,
Ich schreibe hier mal meine test Kommandos damit alle Leute die testen ungefähr wissen was getestet werden muss.
als aller erstes heißt es natürlich code lesen also die Änderungen, um zu schauen das da keine offensichtlichen Fehler sind.
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- logic Fehler im configmode wurden behoben Das Dropdown menu hat, bei wiederholten ausführen des configModes seinen zustand nicht wiederhergestellt. Das setzen zweier uci Parameter ist durch einen Typen Fehler nie zu Stande gekommen.
Das kann man testen in dem man den Router mehrfach hintereinander in den configMode versetzt und die Koordinaten Einstellungen alle einmal durch testet. Zwischendurch immer per ssh schauen ob die Änderungen in der /etc/config/gluon-node-info korrekt eingetragen wurden und ob der zuvor gesetzten Zustände in der Web GUI wieder dargestellt werden.
- Client seitige Javascript map im configeMode Es wird nun vom Router aus via Javascript auf den Client eine OSM Karte geladen, sofern der Client über eine Internet Verbindung verfügt. Um das selektieren von statischen Geo Koordinaten zu vereinfachen.
Hie müssen die unterschiedlichen Koordinaten modi einmal durch selektiert werden Das ganze einmal als Client mit Internetverbindung und einmal ohne. Im falle ohne Internet sollte eine Karte erscheinen und der graue Balken sich nicht verändern.
- hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48 Über respondd werden nun Informationen über die aktuell selektierte hood eines Routers verteilt.
in der shell auf den router sollte mit folgendem Befehl folgendes json erscheinen
root@ffnwDevBox:~# gluon-neighbour-info -i bat0 -p 1001 -d ff02::2 -r hoodselector -t 0.5 {"hoodinfo":{"md5hash":"d213fb718df9f885ad152ee3f47160b5","vpnrouter":"false","hoodname": "default"},"selectedbssid":{"bssid":"02:CA:FF:EE:BA:BF"},"mesh":{"wan":true}}
- hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes der einzelnen hoods.
Das kann man testen indem man mehrere VPN Router aus unterschiedlichen hoods via mesh on lan und wan zusammen schließt. Die Router sollten gegenseitig beim aufrufen von hoodselector in der Konsole ausgeben das mesh on lan / wan deaktiviert wurde auf Grund von ungleichen md5hashes.
- hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.
Nach dem Aufrufen des hoodselectors kann man mit echo $? den Programm return code ausgeben 0 für erfolgreich und 1 für Misserfolg. Einen Misserfolg kann man herbei rufen indem man touch /var/run/hoodselector.pid ausführt und danach die o.g. Routine.
- hoodselector: pid datei write Permission wird abgefangen
joa das ist relativ trevial und kann einfachim code gelesen werden, da es auf den router nicht auftreten kann, da der hoodselector mit root rennt. Daher war diese eine reine Schönheitsänderung im Bezug auf die Router.
- hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)
Das ist im code einzusehen.
- hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40 Das ermöglicht uns anstelle von folgenden zu schreiben: starwars0.sn.ffnw.de 1001 starwars1.sn.ffnw.de 1010 starwars1.sn.ffnw.de 1011
Lediglich: starwars.sn.ffnw.de 1001 starwars.sn.ffnw.de 1010 starwars.sn.ffnw.de 1011 Das reduziert somit die ganzen DNS Einträge.Das kann man testen indem man die hood.json anpasst und z.b. alle default2-6.ffnw.de Adressen auf default.ffnw.de ändert und die Ports alle unterschiedlich setzt. beim aufrufen des hoodselectors sollte die fastd conf angepasst werden. danach sollte in der /etc/config/fastd redundante DNS Einträge mit unterschiedlichen Ports stehen.
- hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN Interfaces die ein Gerät hat. #69
Das kann man testen in dem man zwei dualband Geräte hat und einer auf 2,4 und 5 GHz das mesh ausstrahlt. Der andere dualband Router mesh aber nur auf 5Ghz bei Aufruf des reinen mesh Routers sollte der mit mesh auf 5GHz sich mit den anderen Router verbinden und darüber online gehen. Einstellungen auf welchen Interfaces mesh ausgestrahlt werden soll kann man in configMode einstellen.
- hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec fortgesetzt. #70
aufrufen des hoodselctors im scanmode und sekunden zahlen.
- hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36
Das kann man ebenfalls erzielen indem man touch /var/run/hoodselector.pid aufruft und danach den hoodselechtor ein paar mal hintereinander ausführt. Dann einfach logread und Einträge begutachten.
Schöne Grüße 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
Hi,
mir ist noch ein Fehler bei einem 841 v9 aufgefallen:
"gluon-neighbour-info -i bat0 -p 1001 -d ff02::2 -r hoodselector -t 0.5" Error in sendto(): Permission denied
"hoodselector" VPN connection found. Position found. Set hood "lk-os" Hood set by VPN mode. Error in sendto(): Permission denied Interface mesh_lan enabled.
Die meldung beim hoodselector kommt auch von gluon-neighbour-info
Folgende Fragen hätte ich:
Von welcher Version ausgehend hast du das update ausgeführt?
Wie hast du das update durchgeführt? sysupgrade, webgui ...
Tritt das Problem nach einem Reboot noch auf ?
Magst du hier den logread output posten?
magst du schauen ob unter ps oder top schauen ob respondd noch läuft?
vg Tarek
Hi,
Ich hab von der 1.1.1 geupdatet per sysupgrade. Den Router hab ich mehrfach neugestartet.
Respondd läuft.
Gesendet mit AquaMail für Android http://www.aqua-mail.com
Am 1. Dezember 2016 18:30:17 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
mir ist noch ein Fehler bei einem 841 v9 aufgefallen:
"gluon-neighbour-info -i bat0 -p 1001 -d ff02::2 -r hoodselector -t 0.5" Error in sendto(): Permission denied
"hoodselector" VPN connection found. Position found. Set hood "lk-os" Hood set by VPN mode. Error in sendto(): Permission denied Interface mesh_lan enabled.
Die meldung beim hoodselector kommt auch von gluon-neighbour-info
Folgende Fragen hätte ich:
Von welcher Version ausgehend hast du das update ausgeführt?
Wie hast du das update durchgeführt? sysupgrade, webgui ...
Tritt das Problem nach einem Reboot noch auf ?
Magst du hier den logread output posten?
magst du schauen ob unter ps oder top schauen ob respondd noch läuft?
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Nein, ohne -n. In den Logs tauchen nur die Fehler wie beim ausführen von hoodselector auf.
Wenn du möchtest kann ich dir morgen Zugriff geben.
Gesendet mit AquaMail für Android http://www.aqua-mail.com
Am 1. Dezember 2016 20:21:07 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 12/01/16 20:14, Stefan Dunkel via Dev wrote:
Hi,
Ich hab von der 1.1.1 geupdatet per sysupgrade. Den Router hab ich mehrfach neugestartet.
Hast du sysupgrade -n versucht?
Steht in den logs was?
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 12/01/16 20:22, Stefan Dunkel via Dev wrote:
Nein, ohne -n. In den Logs tauchen nur die Fehler wie beim ausführen von hoodselector auf.
Wenn du möchtest kann ich dir morgen Zugriff geben.
Jo,
Kannst du irgendwie nachweisen das, das problem vorher nicht bestannd ?
Jop, ssh wäre ganz gut :)
vg Tarek
On 12/02/16 10:30, Stefan via Dev wrote:
Hoi,
Am 01.12.2016 um 20:33 schrieb Jan-Tarek Butt via Dev:
Kannst du irgendwie nachweisen das, das problem vorher nicht bestannd ?
der Fehler kam vorher beim Hoodselector nicht.
Ich habe den Fehler gefunden, zumindest Theoretisch. Solange bat0 in der Bridge steckt, sollte netifd IPv6 auf bat0 deaktivieren. Somit sollte darauf gluon-neighbour-info nicht funktionieren.
Das deaktivieren von v6 ist bei allen bisher getesteten Router nicht passiert, außer bei dem 841 v9. Im Grunde nutze die v1.2 einen Bug aus.
Ist das tatsächlich der Fall ziehe ich den Sign Request v1.2 zurück. Prüfen kann ich das erst gleich im Zug oder im Mainframe.
Es gäbe dann zwei Lösungen:
1. Die gluon-neighbour-info abfrage über br-client lösen. Allerdings muss dann gluon-ebtables-filter-multicast fliegen oder geändert werden. Das führt dazu das diese anfrage durch die gesamte hoods geistern. Also minütlich routeranzahl^2 anfragen.
2. Alle lokalen interfaces in der bridge rausfiltern und darüber die gluon-neighbour-info abfrage nur lokal im Netz.
Ich denke es ist offensichtlich das 2. die bessere lösung ist:D
vg Tarek
On 12/02/16 16:00, Jan-Tarek Butt via Dev wrote:
On 12/02/16 10:30, Stefan via Dev wrote:
Hoi,
Am 01.12.2016 um 20:33 schrieb Jan-Tarek Butt via Dev:
Kannst du irgendwie nachweisen das, das problem vorher nicht bestannd ?
der Fehler kam vorher beim Hoodselector nicht.
Ich habe den Fehler gefunden, zumindest Theoretisch. Solange bat0 in der Bridge steckt, sollte netifd IPv6 auf bat0 deaktivieren. Somit sollte darauf gluon-neighbour-info nicht funktionieren.
Das deaktivieren von v6 ist bei allen bisher getesteten Router nicht passiert, außer bei dem 841 v9. Im Grunde nutze die v1.2 einen Bug aus.
Ist das tatsächlich der Fall ziehe ich den Sign Request v1.2 zurück. Prüfen kann ich das erst gleich im Zug oder im Mainframe.
Ich ziehe den Sign Request v1.2 zurück.
vg Tarek
-
Jan-Tarek Butt -
Stefan -
Stefan Dunkel