Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20170822 * Gluon-Version: v2016.2.x * Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971 * Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
* Backport sysupgrade error handling fixes
* prereq: backport changes to git detection to work with newer Git versions
* automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es: package repo:
* Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht.
* Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629......
siteconf repo:
* Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Moin,
ja super schaue ich mir gleich an
könntest du bitte auch eine passenden Testing bauen=?
Gruß
Johannes
Am 23.08.2017 um 17:19 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170822
- Gluon-Version: v2016.2.x
- Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971
- Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Backport sysupgrade error handling fixes
prereq: backport changes to git detection to work with newer Git versions
automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s
wieder rückgängig macht.
- Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz
https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629......
siteconf repo:
- Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ja super schaue ich mir gleich an
könntest du bitte auch eine passenden Testing bauen=?
findet sich hier: https://firmware.ffnw.de/20170822_testing/
vg Tarek
ergebnis bis jetzt: eine gebrickte CPE210 und ein erfolgreich geupdateter mr3020. auf letzterem lief auch schon das hood-test-script durch, Ausgabe unter [1]. Fazit: bis auf butjadingen, landkreis-osnabrueck und oldenburg2 sieht alles ok aus. Weiß jemand, ob es in den genannten hoods gerade irgendein Problem gibt?
[1] https://cloud.ffnw.de/s/BnWhE8JlAj3DatW
hat noch jemand Geräte gebrickt?
LG Lorenz Am 23.08.2017 um 17:19 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170822
- Gluon-Version: v2016.2.x
- Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971
- Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Backport sysupgrade error handling fixes
prereq: backport changes to git detection to work with newer Git versions
automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht.
Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629......
siteconf repo:
- Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
was für Probleme meinst du genau? Die Hoods nehmen jedenfalls VPN Verbindungen auf...
Von meinem iPhone gesendet
Am 23.08.2017 um 23:42 schrieb lrnzo via Dev dev@lists.ffnw.de:
ergebnis bis jetzt: eine gebrickte CPE210 und ein erfolgreich geupdateter mr3020. auf letzterem lief auch schon das hood-test-script durch, Ausgabe unter [1]. Fazit: bis auf butjadingen, landkreis-osnabrueck und oldenburg2 sieht alles ok aus. Weiß jemand, ob es in den genannten hoods gerade irgendein Problem gibt?
[1] https://cloud.ffnw.de/s/BnWhE8JlAj3DatW
hat noch jemand Geräte gebrickt?
LG Lorenz
Am 23.08.2017 um 17:19 schrieb Jan-Tarek Butt via Dev: Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170822
- Gluon-Version: v2016.2.x
- Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971
- Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Backport sysupgrade error handling fixes
prereq: backport changes to git detection to work with newer Git versions
automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s
wieder rückgängig macht.
- Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz
https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629......
siteconf repo:
- Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
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
On 08/23/17 23:42, lrnzo via Dev wrote:
ergebnis bis jetzt: eine gebrickte CPE210 und ein erfolgreich geupdateter mr3020. auf letzterem lief auch schon das hood-test-script durch, Ausgabe unter [1]. Fazit: bis auf butjadingen, landkreis-osnabrueck und oldenburg2 sieht alles ok aus. Weiß jemand, ob es in den genannten hoods gerade irgendein Problem gibt?
Hast du dich mal manuell zu den hoods verbunden und geschaut ob v6 und co gehen ?
hat noch jemand Geräte gebrickt?
Hm.. ja die CPE dinger scheinen für so was ja bekannt zu sein...
Schöne Grüße Tarek
habe einen zweiten test durchlaufen lassen und das Ergebnis hat sich eher verschlechtert. siehe https://cloud.ffnw.de/s/Vu8MuCpURYFSNXr
möglicherweise macht das test-script auch iwo nen Fehler.
manuell testen: ja, aber nicht mehr heute. mal gucken, ob ich auf bornholm dazu komme :)
LG lorenz
Am 24.08.2017 um 00:16 schrieb Jan-Tarek Butt via Dev:
On 08/23/17 23:42, lrnzo via Dev wrote:
ergebnis bis jetzt: eine gebrickte CPE210 und ein erfolgreich geupdateter mr3020. auf letzterem lief auch schon das hood-test-script durch, Ausgabe unter [1]. Fazit: bis auf butjadingen, landkreis-osnabrueck und oldenburg2 sieht alles ok aus. Weiß jemand, ob es in den genannten hoods gerade irgendein Problem gibt?
Hast du dich mal manuell zu den hoods verbunden und geschaut ob v6 und co gehen ?
hat noch jemand Geräte gebrickt?
Hm.. ja die CPE dinger scheinen für so was ja bekannt zu sein...
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin,
Halte ich für unmöglich - die Hoods laufen mit >100 Router jeweils und ich habe nichts zu Problemen gehört. Das sollte man vorher definitiv manuell testen.
Am 24.08.2017 um 01:05 schrieb lrnzo via Dev dev@lists.ffnw.de:
habe einen zweiten test durchlaufen lassen und das Ergebnis hat sich eher verschlechtert. siehe https://cloud.ffnw.de/s/Vu8MuCpURYFSNXr
möglicherweise macht das test-script auch iwo nen Fehler.
manuell testen: ja, aber nicht mehr heute. mal gucken, ob ich auf bornholm dazu komme :)
LG lorenz
Am 24.08.2017 um 00:16 schrieb Jan-Tarek Butt via Dev:
On 08/23/17 23:42, lrnzo via Dev wrote: ergebnis bis jetzt: eine gebrickte CPE210 und ein erfolgreich geupdateter mr3020. auf letzterem lief auch schon das hood-test-script durch, Ausgabe unter [1]. Fazit: bis auf butjadingen, landkreis-osnabrueck und oldenburg2 sieht alles ok aus. Weiß jemand, ob es in den genannten hoods gerade irgendein Problem gibt?
Hast du dich mal manuell zu den hoods verbunden und geschaut ob v6 und co gehen ?
hat noch jemand Geräte gebrickt?
Hm.. ja die CPE dinger scheinen für so was ja bekannt zu sein...
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
so, mittlerweile läuft das testskript in weniger als 15 min durch alle 24 hoods durch, wobei es 2mal 2min vergeblich auf v6-Adressen gewartet hat. Ausgabe siehe [1]
Allerdings ist es immer noch so, dass ein per wired-mesh angeschlossener router (uplink + meshrouter sind bei mir Virtualbox VMs) vom hoodselector immer in die Defaulthood geschoben wird:
---------------------------8<--------------------------- hoodselector No VPN connection found Batman gateways found gw source is wan gluon-neighbour-info -i br-wan -p 1001 -d ff02::2 -r hoodselector -t 0.5 No VPN routers over mesh on lan or wan gluon-neighbour-info -i br-wan -p 1001 -d ff02::2 -r hoodselector -t 0.5 gluon-neighbour-info -i br-client -p 1001 -d ff02::2 -r hoodselector -t 0.5 No VPN routers over mesh on lan or wan No molwm neighbors found currend configuration are not defined as hood Set hood "default" Set defaulthood. --------------------------->8---------------------------
ist das das gewünschte Verhalten? Ich glaube nicht, weil das ja immer dazu führt, dass wlan-router hinter zB. offloadern eine falsche bssid senden.
[1] https://cloud.ffnw.de/s/uLGLR89oeqiwaYw
Schöne Grüße vom bornhack.dk
Am 24.08.2017 um 10:07 schrieb Stefan Dunkel via Dev:
Moin,
Halte ich für unmöglich - die Hoods laufen mit >100 Router jeweils und ich habe nichts zu Problemen gehört. Das sollte man vorher definitiv manuell testen.
Am 24.08.2017 um 01:05 schrieb lrnzo via Dev dev@lists.ffnw.de:
habe einen zweiten test durchlaufen lassen und das Ergebnis hat sich eher verschlechtert. siehe https://cloud.ffnw.de/s/Vu8MuCpURYFSNXr
möglicherweise macht das test-script auch iwo nen Fehler.
manuell testen: ja, aber nicht mehr heute. mal gucken, ob ich auf bornholm dazu komme :)
LG lorenz
Am 24.08.2017 um 00:16 schrieb Jan-Tarek Butt via Dev:
On 08/23/17 23:42, lrnzo via Dev wrote: ergebnis bis jetzt: eine gebrickte CPE210 und ein erfolgreich geupdateter mr3020. auf letzterem lief auch schon das hood-test-script durch, Ausgabe unter [1]. Fazit: bis auf butjadingen, landkreis-osnabrueck und oldenburg2 sieht alles ok aus. Weiß jemand, ob es in den genannten hoods gerade irgendein Problem gibt?
Hast du dich mal manuell zu den hoods verbunden und geschaut ob v6 und co gehen ?
hat noch jemand Geräte gebrickt?
Hm.. ja die CPE dinger scheinen für so was ja bekannt zu sein...
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
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Allerdings ist es immer noch so, dass ein per wired-mesh angeschlossener router (uplink + meshrouter sind bei mir Virtualbox VMs) vom hoodselector immer in die Defaulthood geschoben wird:
---------------------------8<--------------------------- hoodselector No VPN connection found Batman gateways found gw source is wan gluon-neighbour-info -i br-wan -p 1001 -d ff02::2 -r hoodselector -t 0.5 No VPN routers over mesh on lan or wan gluon-neighbour-info -i br-wan -p 1001 -d ff02::2 -r hoodselector -t 0.5 gluon-neighbour-info -i br-client -p 1001 -d ff02::2 -r hoodselector -t 0.5 No VPN routers over mesh on lan or wan No molwm neighbors found currend configuration are not defined as hood Set hood "default" Set defaulthood. --------------------------->8---------------------------
ist das das gewünschte Verhalten? Ich glaube nicht, weil das ja immer dazu führt, dass wlan-router hinter zB. offloadern eine falsche bssid senden.
Es kann durchaus ein paar Minuten dauern biss respondd die Daten bereitstellt.
wie viele Minuten war dein versuch nach dem Start?
Magst du mal auf beiden Kisten also den uplink und dem mesh node folgendes manuell ausführen:
Bei mesh on WAN: gluon-neighbour-info -i br-wan -p 1001 -d ff02::2 -r hoodselector -t 0.5
Bei mesh on LAN: gluon-neighbour-info -i br-client -p 1001 -d ff02::2 -r hoodselector -t 0.5
Dort solltest du entsprechend JSON output bekommen.
Der o.g. node sieht scheinbar garkeine nachbarn.
vg Tarek
On 08/27/17 17:20, lrnzo via Dev wrote:
öhm ... müsste das bei MoL nicht
gluon-neighbour-info -i br-mesh_lan -p 1001 -d ff02::2 -r hoodselector -t 0.5
sein?
Ich bin mir gerade nicht sicher da müsste ich jetzt auch gerade in den gluon Code schauen. Ich glaube aber br-mesh_lan ist die bridge in der u.a. br-client enthalten sind. Aber wie gesagt ich bin mir gerade nicht sicher. br-client ist hier aber schon das richtige Interface. Denn der hoodselector holt sich die respondd Interfaces von respondd selbst und probiert alle durch. D.h. dein o.g. Kommando wird wahrscheinlich nix oder einen Fehler zurückgeliefert werden.
vg Tarek
ja, du hast Recht.
Andere Frage: wenn ich es richtig verstanden habe, guckt sich der hoodselector ja den Eintrag selectedbssid.bssid bei den mesh-on-l/wan routern an. Das Problem daran: offloader wählen niemals eine Bssid aus, weil das idR Kisten ohne wlan sind. Entsprechend sieht es für router hinter offloadern auch immer so aus, als gäbe es keine wired-mesh vpn-Router. Daher jetzt meine Frage: könnte man nicht statt selectedbssid.bssid genauso gut mesh.bssid testen? Diesen haben nämlich auch offloader. Oder schafft man sich damit neue Probleme?
habe hierzu mal einen branch mit entsprenchenden commits gepusht
lg Lorenz
Am 27.08.2017 um 19:11 schrieb Jan-Tarek Butt via Dev:
On 08/27/17 17:20, lrnzo via Dev wrote:
öhm ... müsste das bei MoL nicht
gluon-neighbour-info -i br-mesh_lan -p 1001 -d ff02::2 -r hoodselector -t 0.5
sein?
Ich bin mir gerade nicht sicher da müsste ich jetzt auch gerade in den gluon Code schauen. Ich glaube aber br-mesh_lan ist die bridge in der u.a. br-client enthalten sind. Aber wie gesagt ich bin mir gerade nicht sicher. br-client ist hier aber schon das richtige Interface. Denn der hoodselector holt sich die respondd Interfaces von respondd selbst und probiert alle durch. D.h. dein o.g. Kommando wird wahrscheinlich nix oder einen Fehler zurückgeliefert werden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Andere Frage: wenn ich es richtig verstanden habe, guckt sich der hoodselector ja den Eintrag selectedbssid.bssid bei den mesh-on-l/wan routern an. Das Problem daran: offloader wählen niemals eine Bssid aus, weil das idR Kisten ohne wlan sind. Entsprechend sieht es für router hinter offloadern auch immer so aus, als gäbe es keine wired-mesh vpn-Router. Daher jetzt meine Frage: könnte man nicht statt selectedbssid.bssid genauso gut mesh.bssid testen? Diesen haben nämlich auch offloader. Oder schafft man sich damit neue Probleme?
Diese sogenanten mesh.bssid habe ich im hoodselector implementiert. Vorher gab es sowas nicht. Offloarder setzen iher "BSSID" via geokoordinaten und diese sehen auch benachbarte mesh lan/wan router.
habe hierzu mal einen branch mit entsprenchenden commits gepusht.
Ich schaue es mir gerade an :-)
Schöne grüße aus Spanien Tarek
Am 04.09.2017 um 05:54 schrieb Jan-Tarek Butt via Dev:
Andere Frage: wenn ich es richtig verstanden habe, guckt sich der hoodselector ja den Eintrag selectedbssid.bssid bei den mesh-on-l/wan routern an. Das Problem daran: offloader wählen niemals eine Bssid aus, weil das idR Kisten ohne wlan sind. Entsprechend sieht es für router hinter offloadern auch immer so aus, als gäbe es keine wired-mesh vpn-Router. Daher jetzt meine Frage: könnte man nicht statt selectedbssid.bssid genauso gut mesh.bssid testen? Diesen haben nämlich auch offloader. Oder schafft man sich damit neue Probleme?
Diese sogenanten mesh.bssid habe ich im hoodselector implementiert. Vorher gab es sowas nicht. Offloarder setzen iher "BSSID" via geokoordinaten und diese sehen auch benachbarte mesh lan/wan router.
ja, genau. Deshalb könnte der hoodselector in der Funktion molw_get_bssid diese mesh.bssid nutzen, falls die selectedbssid.bssid nicht existiert.
habe hierzu mal einen branch mit entsprenchenden commits gepusht.
Ich schaue es mir gerade an :-)
neben der Funktion molw_get_bssid habe ich noch an diversen Stelle die Einrückungen angefasst. Der Commit ist deshalb leider etwas umfangreich geworden. Ich gelobe Besserung. Außerdem fehlte im VPN-Mode imho noch ein else-Statement, das habe ich mal ergänzt.
Schöne grüße aus Spanien Tarek
Schöne Grüße aus Greifswald Lorenz
On 09/04/17 09:29, lrnzo via Dev wrote:
Am 04.09.2017 um 05:54 schrieb Jan-Tarek Butt via Dev:
Andere Frage: wenn ich es richtig verstanden habe, guckt sich der hoodselector ja den Eintrag selectedbssid.bssid bei den mesh-on-l/wan routern an. Das Problem daran: offloader wählen niemals eine Bssid aus, weil das idR Kisten ohne wlan sind. Entsprechend sieht es für router hinter offloadern auch immer so aus, als gäbe es keine wired-mesh vpn-Router. Daher jetzt meine Frage: könnte man nicht statt selectedbssid.bssid genauso gut mesh.bssid testen? Diesen haben nämlich auch offloader. Oder schafft man sich damit neue Probleme?
Diese sogenanten mesh.bssid habe ich im hoodselector implementiert. Vorher gab es sowas nicht. Offloarder setzen iher "BSSID" via geokoordinaten und diese sehen auch benachbarte mesh lan/wan router.
ja, genau. Deshalb könnte der hoodselector in der Funktion molw_get_bssid diese mesh.bssid nutzen, falls die selectedbssid.bssid nicht existiert.
habe hierzu mal einen branch mit entsprenchenden commits gepusht.
Ich schaue es mir gerade an :-)
neben der Funktion molw_get_bssid habe ich noch an diversen Stelle die Einrückungen angefasst. Der Commit ist deshalb leider etwas umfangreich geworden. Ich gelobe Besserung. Außerdem fehlte im VPN-Mode imho noch ein else-Statement, das habe ich mal ergänzt.
Danke dir, ich hab es nur mal grob überflogen.
Wenn du der Meinung bist das Änderungen von dir in deinen branch soweit bereit für einen Merge sind, kannst du einfach einen Merge Request stellen und dann können sich andere deine Änderungen die und vorschlägst angucken. :)
vg Tarek
Hallo zusammen,
habe die Version getestet und gesigned. Ich haue gleich einen Blogpost raus und biege dann den Symlink um.
VG
Stefan
Am 04.09.2017 um 09:43 schrieb Jan-Tarek Butt via Dev:
On 09/04/17 09:29, lrnzo via Dev wrote:
Am 04.09.2017 um 05:54 schrieb Jan-Tarek Butt via Dev:
Andere Frage: wenn ich es richtig verstanden habe, guckt sich der hoodselector ja den Eintrag selectedbssid.bssid bei den mesh-on-l/wan routern an. Das Problem daran: offloader wählen niemals eine Bssid aus, weil das idR Kisten ohne wlan sind. Entsprechend sieht es für router hinter offloadern auch immer so aus, als gäbe es keine wired-mesh vpn-Router. Daher jetzt meine Frage: könnte man nicht statt selectedbssid.bssid genauso gut mesh.bssid testen? Diesen haben nämlich auch offloader. Oder schafft man sich damit neue Probleme?
Diese sogenanten mesh.bssid habe ich im hoodselector implementiert. Vorher gab es sowas nicht. Offloarder setzen iher "BSSID" via geokoordinaten und diese sehen auch benachbarte mesh lan/wan router.
ja, genau. Deshalb könnte der hoodselector in der Funktion molw_get_bssid diese mesh.bssid nutzen, falls die selectedbssid.bssid nicht existiert.
habe hierzu mal einen branch mit entsprenchenden commits gepusht.
Ich schaue es mir gerade an :-)
neben der Funktion molw_get_bssid habe ich noch an diversen Stelle die Einrückungen angefasst. Der Commit ist deshalb leider etwas umfangreich geworden. Ich gelobe Besserung. Außerdem fehlte im VPN-Mode imho noch ein else-Statement, das habe ich mal ergänzt.
Danke dir, ich hab es nur mal grob überflogen.
Wenn du der Meinung bist das Änderungen von dir in deinen branch soweit bereit für einen Merge sind, kannst du einfach einen Merge Request stellen und dann können sich andere deine Änderungen die und vorschlägst angucken. :)
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
ich wollte gerade signen, aber das manifest liegt nicht unter srv01.ffnw.de:/var/www/dev/firmware/20170822/stable.manifest, wo laut Doku [1] doch liegen sollte, oder?
[1] https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Am 23.08.2017 um 17:19 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170822
- Gluon-Version: v2016.2.x
- Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971
- Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Backport sysupgrade error handling fixes
prereq: backport changes to git detection to work with newer Git versions
automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht.
Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629......
siteconf repo:
- Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ich wollte gerade signen, aber das manifest liegt nicht unter srv01.ffnw.de:/var/www/dev/firmware/20170822/stable.manifest, wo laut Doku [1] doch liegen sollte, oder?
[1] https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Die Firmware wurde vom adminteam umgezogen. Du kannst am besten folgende url nutzen: firmware.ffnw.de
vg Tarek
ok, signed
Am 04.09.2017 um 06:04 schrieb Jan-Tarek Butt via Dev:
Hi,
ich wollte gerade signen, aber das manifest liegt nicht unter srv01.ffnw.de:/var/www/dev/firmware/20170822/stable.manifest, wo laut Doku [1] doch liegen sollte, oder?
[1] https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Die Firmware wurde vom adminteam umgezogen. Du kannst am besten folgende url nutzen: firmware.ffnw.de
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
sorry, ich war mit den Versionen durcheinander gekommen. DIESE Version (20170822) müßte noch von möglichst vielen Leute gesigned werden, damit Router wie dieser hier:
https://map.ffnw.de/#/de/map/c46e1fdf0b00
updaten können.
LG Lorenz
Am 23.08.2017 um 17:19 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20170822
- Gluon-Version: v2016.2.x
- Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971
- Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Backport sysupgrade error handling fixes
prereq: backport changes to git detection to work with newer Git versions
automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht.
Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629......
siteconf repo:
- Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629......
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Jan-Tarek Butt -
Johannes Rudolph -
lrnzo -
Stefan Dunkel