Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20171010 * Gluon-Version: v2017.1.x * Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7 * Download: https://firmware.ffnw.de/20171010
Folgende Gluon spezifischen Änderungen gab es unter anderen:
* Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist. Die LEDE basis von Gluon ist nun v17.01.3. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3].
* Der Kernel wurde von 3.18.x auf v4.4.89 geupgraded.
* Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig waren wurden entfernt.
* das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
* Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
* Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
* Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber verbessert (#605).
* Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [4].
* batman-adv wurde auf Version 2017.1 geupdated [5].
* GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
* Support für tunneldigger mesh VPN
* Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
* batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
* Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
* dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
* Einige security Issues wurden in Paketen behoben die in der regel nicht teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [6]
* Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
* Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http:// starten (9ab93992d1fc).
* Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock Firmware installiert wird (#1223).
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...3e2e72
Folgende Comunnity spezifischen Änderungen gab es: package repo:
* Das Paket "11s-switch" ist hinzugekommen. Diese sorgt dafür, das die Router von IBSS (AD-HOC) auf 11s mesh wechseln. Der wechsel findet am 24.10.2017 statt.
* Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht ist entfernt.
* Das Paket ffnw-config-mode-geo-location wurde aktualisiert, und nutzt jetzt minified js.
* Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
* Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
* Das Paket hoodselectorctl wurde entfernt.
* Das Paket nodewatcher2 wurde entfernt.
* Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche eindeutig ist, Anstelle des hoodnames.
* Der hoodselector prüft im Radiolest Mode prüfe ob mesh on lan/wan an ist.
* Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte. diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
* Ein paar patches die den umgeng mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
* Das Modul netmon wurde entfernt.
* fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
* autoupdater good signatures level ist auf 5 gestiegen.
* Geräte mit ATH10K sind in dieser version raus geflogen. Folgende Geräte erhalten das update nicht: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro.
* Die update Priorität wurde von 0 auf 2 erhöht. D.h. es dauert mindestens 2 tage bis alle Geräte das Update erhalten.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
* Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [7] upgraden, bevor diese 20171005 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltes du vor den update auf 20171005 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Eine Firmware für die Geräte: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro wird es am 24.10.2017 geben. Grund dafür ist das es nicht möglich ist, 11s und IBSS in einer Firmware zu bauen. Ein update dieser Geräte muss daher manuell erfolgen, wenn es sich um einen mesh only gerät handelt.
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [5] https://www.open-mesh.org/news/78 [6] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [7] https://firmware.ffnw.de/20170822/
sysupgrade -T -v gluon-ffnw-20171010-tp-link-tl-wr1043n-nd-v4-sysupgrade.bin Image metadata not found
schlimm? update lief zumindest durch
Am 10.10.2017 um 23:45 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171010
- Gluon-Version: v2017.1.x
- Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7
- Download: https://firmware.ffnw.de/20171010
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist. Die LEDE basis von Gluon ist nun v17.01.3. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3].
Der Kernel wurde von 3.18.x auf v4.4.89 geupgraded.
Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig waren wurden entfernt.
das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber verbessert (#605).
Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [4].
batman-adv wurde auf Version 2017.1 geupdated [5].
GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
Support für tunneldigger mesh VPN
Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
Einige security Issues wurden in Paketen behoben die in der regel nicht teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [6]
Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http:// starten (9ab93992d1fc).
Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock Firmware installiert wird (#1223).
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...3e2e72
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Das Paket "11s-switch" ist hinzugekommen. Diese sorgt dafür, das die Router von IBSS (AD-HOC) auf 11s mesh wechseln. Der wechsel findet am 24.10.2017 statt.
Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht ist entfernt.
Das Paket ffnw-config-mode-geo-location wurde aktualisiert, und nutzt jetzt minified js.
Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
Das Paket hoodselectorctl wurde entfernt.
Das Paket nodewatcher2 wurde entfernt.
Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche eindeutig ist, Anstelle des hoodnames.
Der hoodselector prüft im Radiolest Mode prüfe ob mesh on lan/wan an ist.
Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte. diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
Ein paar patches die den umgeng mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
Das Modul netmon wurde entfernt.
fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
autoupdater good signatures level ist auf 5 gestiegen.
Geräte mit ATH10K sind in dieser version raus geflogen. Folgende Geräte erhalten das update nicht: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro.
Die update Priorität wurde von 0 auf 2 erhöht. D.h. es dauert mindestens 2 tage bis alle Geräte das Update erhalten.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
- Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [7] upgraden, bevor diese 20171005 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltes du vor den update auf 20171005 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Eine Firmware für die Geräte: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro wird es am 24.10.2017 geben. Grund dafür ist das es nicht möglich ist, 11s und IBSS in einer Firmware zu bauen. Ein update dieser Geräte muss daher manuell erfolgen, wenn es sich um einen mesh only gerät handelt.
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [5] https://www.open-mesh.org/news/78 [6] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [7] https://firmware.ffnw.de/20170822/
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
ich antworte mal in diesem Thread auf stefans Mail ...
die Erhöhung der Signatures auf 5 sehe ich nicht jetzt nicht so als Problem. ZB wurde die 20170530 von 6 Leuten signiert (siehe https://firmware.ffnw.de/status.html)
der switch auf 11s erfolgt ja auch nicht mit dem update, sondern ein paar tage danach. um genau sein am 27.10:
date -d $(cat /lib/ffnw/11s-switch/fdate) Tue Oct 27 02:27:00 CET 2015
also eigentlich massig Zeit. noch. wenn aber der 5-te erst am 26-ten signed, gehen natürlich die Probleme los. Ich würde für folgendes Vorgehen plädieren: wenn nicht bis zum 20.10. 4 signs da sind, sollte der sign-request zurückgezogen werden.
Senftube leer
LG Lorenz
Am 11.10.2017 um 10:44 schrieb Stefan via Dev:
Guten Morgen zusammen,
ich habe bei der Firwmare Version echte Bauchschmerzen, diese über das Netz zu verteilen. Mehrere Punkte sind mir aufgefallen:
- Signaturen auf 5 hochgesetzt - wir haben wieder 2 Leichen in der Sign
Liste, die niemals etwas signiert haben. Ich wäre dafür, weiterhin auf 4 Signs zu setzen.
- Der 11s Switch mag funktionieren, jedoch werden wir dadruch viele
Router verlieren, da zu dem Zeitpunkt vielleicht Router offline sind, aus welchen Gründen auch immer. Ich wäre hier eindeutig dafür, dass wir für wenige Tage einen Parralelbetrieb fahren, sodass nach X Tagen dann IBSS erst abgeschaltet wird, sodass alle Router die Möglichkeit haben, sich zu updaten.
Besonders der 2. Punkt macht mir Sorgen - sorry, von meiner Seite werde ich das so nicht signen.
Am 10.10.2017 um 23:45 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171010
- Gluon-Version: v2017.1.x
- Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7
- Download: https://firmware.ffnw.de/20171010
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist. Die LEDE basis von Gluon ist nun v17.01.3. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3].
Der Kernel wurde von 3.18.x auf v4.4.89 geupgraded.
Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig waren wurden entfernt.
das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber verbessert (#605).
Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [4].
batman-adv wurde auf Version 2017.1 geupdated [5].
GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
Support für tunneldigger mesh VPN
Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
Einige security Issues wurden in Paketen behoben die in der regel nicht teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [6]
Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http:// starten (9ab93992d1fc).
Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock Firmware installiert wird (#1223).
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...3e2e72
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Das Paket "11s-switch" ist hinzugekommen. Diese sorgt dafür, das die Router von IBSS (AD-HOC) auf 11s mesh wechseln. Der wechsel findet am 24.10.2017 statt.
Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht ist entfernt.
Das Paket ffnw-config-mode-geo-location wurde aktualisiert, und nutzt jetzt minified js.
Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
Das Paket hoodselectorctl wurde entfernt.
Das Paket nodewatcher2 wurde entfernt.
Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche eindeutig ist, Anstelle des hoodnames.
Der hoodselector prüft im Radiolest Mode prüfe ob mesh on lan/wan an ist.
Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte. diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
Ein paar patches die den umgeng mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
Das Modul netmon wurde entfernt.
fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
autoupdater good signatures level ist auf 5 gestiegen.
Geräte mit ATH10K sind in dieser version raus geflogen. Folgende Geräte erhalten das update nicht: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro.
Die update Priorität wurde von 0 auf 2 erhöht. D.h. es dauert mindestens 2 tage bis alle Geräte das Update erhalten.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
- Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [7] upgraden, bevor diese 20171005 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltes du vor den update auf 20171005 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Eine Firmware für die Geräte: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro wird es am 24.10.2017 geben. Grund dafür ist das es nicht möglich ist, 11s und IBSS in einer Firmware zu bauen. Ein update dieser Geräte muss daher manuell erfolgen, wenn es sich um einen mesh only gerät handelt.
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [5] https://www.open-mesh.org/news/78 [6] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [7] https://firmware.ffnw.de/20170822/
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin
Ich teile ebenfalls alle diese Bedenken
Lass uns 2 Firmwares bauen eine die beides aktiviert hat (AdHoc und 11s) und eine die nur 11s hat
Wenn beide firmwares signiert sind!!! rollen wir die Firmware die beides aktiviert hat aus. Wenn wir dann sehen, dass alles das Update erhalten haben rollen wir das zweite Firmware direkt aus die ja schon signiert ist und nur darauf wartet aktiviert zu werden.
Wir haben ja schon mal 2 Monate beides aktiv gehabt also funktionieren kann das so!
Ich habe auch ein Problem das Signatur Level hochzusetzten weil 2 Leute (fkr und lethexa (Mein Kollege) ) noch nie signiert haben meines Erachtens können wir die auch rausnehmen.
Ich werde Status aktuell So auch nicht signieren!
Das Harte Datum 27.10 stört mich und ist viel zu nah an heute dran!
Gruß
Johannes
Am 11.10.2017 um 11:34 schrieb lrnzo via Dev dev@lists.ffnw.de:
ich antworte mal in diesem Thread auf stefans Mail ...
die Erhöhung der Signatures auf 5 sehe ich nicht jetzt nicht so als Problem. ZB wurde die 20170530 von 6 Leuten signiert (siehe https://firmware.ffnw.de/status.html)
der switch auf 11s erfolgt ja auch nicht mit dem update, sondern ein paar tage danach. um genau sein am 27.10:
date -d $(cat /lib/ffnw/11s-switch/fdate) Tue Oct 27 02:27:00 CET 2015
also eigentlich massig Zeit. noch. wenn aber der 5-te erst am 26-ten signed, gehen natürlich die Probleme los. Ich würde für folgendes Vorgehen plädieren: wenn nicht bis zum 20.10. 4 signs da sind, sollte der sign-request zurückgezogen werden.
Senftube leer
LG Lorenz
Am 11.10.2017 um 10:44 schrieb Stefan via Dev: Guten Morgen zusammen,
ich habe bei der Firwmare Version echte Bauchschmerzen, diese über das Netz zu verteilen. Mehrere Punkte sind mir aufgefallen:
- Signaturen auf 5 hochgesetzt - wir haben wieder 2 Leichen in der Sign
Liste, die niemals etwas signiert haben. Ich wäre dafür, weiterhin auf 4 Signs zu setzen.
- Der 11s Switch mag funktionieren, jedoch werden wir dadruch viele
Router verlieren, da zu dem Zeitpunkt vielleicht Router offline sind, aus welchen Gründen auch immer. Ich wäre hier eindeutig dafür, dass wir für wenige Tage einen Parralelbetrieb fahren, sodass nach X Tagen dann IBSS erst abgeschaltet wird, sodass alle Router die Möglichkeit haben, sich zu updaten.
Besonders der 2. Punkt macht mir Sorgen - sorry, von meiner Seite werde ich das so nicht signen.
Am 10.10.2017 um 23:45 schrieb Jan-Tarek Butt via Dev: Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171010
- Gluon-Version: v2017.1.x
- Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7
- Download: https://firmware.ffnw.de/20171010
Folgende Gluon spezifischen Änderungen gab es unter anderen:
- Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist.
Die LEDE basis von Gluon ist nun v17.01.3. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3].
Der Kernel wurde von 3.18.x auf v4.4.89 geupgraded.
Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig
waren wurden entfernt.
das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise
einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
- Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen
führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
- Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber
verbessert (#605).
- Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer
Erlebnis verbessern (#1000). Siehe dazu auch [4].
batman-adv wurde auf Version 2017.1 geupdated [5].
GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
Support für tunneldigger mesh VPN
Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von
management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
- batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein
wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
- Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V)
in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
- dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704,
CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
- Einige security Issues wurden in Paketen behoben die in der regel nicht teil der
Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [6]
- Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde
gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
- Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http://
starten (9ab93992d1fc).
- Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock
Firmware installiert wird (#1223).
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...3e2e72
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- Das Paket "11s-switch" ist hinzugekommen. Diese sorgt dafür, das die Router von
IBSS (AD-HOC) auf 11s mesh wechseln. Der wechsel findet am 24.10.2017 statt.
- Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s
wieder rückgängig macht ist entfernt.
Das Paket ffnw-config-mode-geo-location wurde aktualisiert, und nutzt jetzt minified js.
Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
Das Paket hoodselectorctl wurde entfernt.
Das Paket nodewatcher2 wurde entfernt.
Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche
eindeutig ist, Anstelle des hoodnames.
Der hoodselector prüft im Radiolest Mode prüfe ob mesh on lan/wan an ist.
Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte.
diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
Ein paar patches die den umgeng mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
Das Modul netmon wurde entfernt.
fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel
aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
autoupdater good signatures level ist auf 5 gestiegen.
Geräte mit ATH10K sind in dieser version raus geflogen.
Folgende Geräte erhalten das update nicht: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro.
- Die update Priorität wurde von 0 auf 2 erhöht. D.h. es dauert mindestens 2 tage bis
alle Geräte das Update erhalten.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
- Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [7] upgraden, bevor diese 20171005 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltes du vor den update auf 20171005 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Eine Firmware für die Geräte: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro wird es am 24.10.2017 geben. Grund dafür ist das es nicht möglich ist, 11s und IBSS in einer Firmware zu bauen. Ein update dieser Geräte muss daher manuell erfolgen, wenn es sich um einen mesh only gerät handelt.
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [5] https://www.open-mesh.org/news/78 [6] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [7] https://firmware.ffnw.de/20170822/
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
achnee warte, da war doch noch Senf. ausgerollt wird ja erst mit dem ändern des symlinks und nicht mit dem letzten sign. Daher: wenn bis zum Tag X nicht alle signs da sind, wird nicht der symlink umgebogen, sondern der SR zurückgezogen und eine neue FW gebaut.
Am 11.10.2017 um 11:34 schrieb lrnzo via Dev:
ich antworte mal in diesem Thread auf stefans Mail ...
die Erhöhung der Signatures auf 5 sehe ich nicht jetzt nicht so als Problem. ZB wurde die 20170530 von 6 Leuten signiert (siehe https://firmware.ffnw.de/status.html)
der switch auf 11s erfolgt ja auch nicht mit dem update, sondern ein paar tage danach. um genau sein am 27.10:
date -d $(cat /lib/ffnw/11s-switch/fdate) Tue Oct 27 02:27:00 CET 2015
also eigentlich massig Zeit. noch. wenn aber der 5-te erst am 26-ten signed, gehen natürlich die Probleme los. Ich würde für folgendes Vorgehen plädieren: wenn nicht bis zum 20.10. 4 signs da sind, sollte der sign-request zurückgezogen werden.
Senftube leer
LG Lorenz
Am 11.10.2017 um 10:44 schrieb Stefan via Dev:
Guten Morgen zusammen,
ich habe bei der Firwmare Version echte Bauchschmerzen, diese über das Netz zu verteilen. Mehrere Punkte sind mir aufgefallen:
- Signaturen auf 5 hochgesetzt - wir haben wieder 2 Leichen in der Sign
Liste, die niemals etwas signiert haben. Ich wäre dafür, weiterhin auf 4 Signs zu setzen.
- Der 11s Switch mag funktionieren, jedoch werden wir dadruch viele
Router verlieren, da zu dem Zeitpunkt vielleicht Router offline sind, aus welchen Gründen auch immer. Ich wäre hier eindeutig dafür, dass wir für wenige Tage einen Parralelbetrieb fahren, sodass nach X Tagen dann IBSS erst abgeschaltet wird, sodass alle Router die Möglichkeit haben, sich zu updaten.
Besonders der 2. Punkt macht mir Sorgen - sorry, von meiner Seite werde ich das so nicht signen.
Am 10.10.2017 um 23:45 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171010
- Gluon-Version: v2017.1.x
- Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7
- Download: https://firmware.ffnw.de/20171010
Folgende Gluon spezifischen Änderungen gab es unter anderen:
Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet war/ist. Die LEDE basis von Gluon ist nun v17.01.3. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3].
Der Kernel wurde von 3.18.x auf v4.4.89 geupgraded.
Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt notwendig waren wurden entfernt.
das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
Eine race condition im Netzwerk setup scripts konnte zu unvollständigen Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k Treiber verbessert (#605).
Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [4].
batman-adv wurde auf Version 2017.1 geupdated [5].
GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
Support für tunneldigger mesh VPN
Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben: CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
Einige security Issues wurden in Paketen behoben die in der regel nicht teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [6]
Das Filtern von multicast paketen zwischen dem mesh und local-node interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs nicht mit http:// starten (9ab93992d1fc).
Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren stock Firmware installiert wird (#1223).
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...3e2e72
Folgende Comunnity spezifischen Änderungen gab es: package repo:
Das Paket "11s-switch" ist hinzugekommen. Diese sorgt dafür, das die Router von IBSS (AD-HOC) auf 11s mesh wechseln. Der wechsel findet am 24.10.2017 statt.
Das Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s wieder rückgängig macht ist entfernt.
Das Paket ffnw-config-mode-geo-location wurde aktualisiert, und nutzt jetzt minified js.
Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00 korrigiert.
Das Paket hoodselectorctl wurde entfernt.
Das Paket nodewatcher2 wurde entfernt.
Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der hood, welche eindeutig ist, Anstelle des hoodnames.
Der hoodselector prüft im Radiolest Mode prüfe ob mesh on lan/wan an ist.
Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart hatte. diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822......
siteconf repo:
Ein paar patches die den umgeng mit IEEE802.11s in openWRT ermöglichen wurden entfernt.
Das Modul netmon wurde entfernt.
fastd kann nun auch die crypt Methode 'null' was bedeutet das ein unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
autoupdater good signatures level ist auf 5 gestiegen.
Geräte mit ATH10K sind in dieser version raus geflogen. Folgende Geräte erhalten das update nicht: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro.
Die update Priorität wurde von 0 auf 2 erhöht. D.h. es dauert mindestens 2 tage bis alle Geräte das Update erhalten.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822......
- Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [7] upgraden, bevor diese 20171005 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltes du vor den update auf 20171005 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Eine Firmware für die Geräte: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro wird es am 24.10.2017 geben. Grund dafür ist das es nicht möglich ist, 11s und IBSS in einer Firmware zu bauen. Ein update dieser Geräte muss daher manuell erfolgen, wenn es sich um einen mesh only gerät handelt.
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [5] https://www.open-mesh.org/news/78 [6] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [7] https://firmware.ffnw.de/20170822/
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 10/11/17 11:34, lrnzo via Dev wrote:
ich antworte mal in diesem Thread auf stefans Mail ...
die Erhöhung der Signatures auf 5 sehe ich nicht jetzt nicht so als Problem. ZB wurde die 20170530 von 6 Leuten signiert (siehe https://firmware.ffnw.de/status.html)
Die Erhöhung läuft nach unser Konvention siehe folgenden Link: https://wiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
der switch auf 11s erfolgt ja auch nicht mit dem update, sondern ein paar tage danach. um genau sein am 27.10:
date -d $(cat /lib/ffnw/11s-switch/fdate) Tue Oct 27 02:27:00 CET 2015
@stefan: Das was du in deiner Mail geschrieben hast macht der 11s-switch im Grunde. Die Router betreiben ganz normal das ibss Netz und alle Router auch die, die ein paar tage offline waren haben die Möglichkeit die Firmware zu bekommen. Erst in Zweiwochen (wie es besprochen war) ersetzt der 11s-switcher die identische site.conf nur eben mit 11s und lädt die wifi config neu.
Das haben wir 3 mal getestet in verschiedenen mesh Konstellationen.
also eigentlich massig Zeit. noch. wenn aber der 5-te erst am 26-ten signed, gehen natürlich die Probleme los. Ich würde für folgendes Vorgehen plädieren: wenn nicht bis zum 20.10. 4 signs da sind, sollte der sign-request zurückgezogen werden.
Ich würde sogar sagen das wir bis zum 17. alle Signaturen komplett haben müssen. Um den symlink um zu biegen.
vg Tarek
Hallo,
Ich teile ebenfalls alle diese Bedenken
Lass uns 2 Firmwares bauen eine die beides aktiviert hat (AdHoc und 11s) und eine die nur 11s hat> Wenn beide firmwares signiert sind!!! rollen wir die Firmware die beides aktiviert hat aus. Wenn wir dann sehen, dass alles das Update erhalten haben rollen wir das zweite Firmware direkt aus die ja schon signiert ist und nur darauf wartet aktiviert zu werden.
Wir haben ja schon mal 2 Monate beides aktiv gehabt also funktionieren kann das so!
Darüber hatten wir bereits Diskutiert. Die Netze Parallel funktionieren sehr instabil und es hat zu einigen kaputten Routern geführt. Siehe Betreff [Dev] Umstellung auf 11s
Im Grunde Tausch der 11s-switcher nur die site.con gegen eine ohne ibss aus. Quasi genau das was wir mit dem Bau einer Firmware machen würden. Wo wir einfach die identische Firmware bauen würden nur eben mit und und ohne ibss.
Ich habe auch ein Problem das Signatur Level hochzusetzten weil 2 Leute (fkr und lethexa (Mein Kollege) ) noch nie signiert haben meines Erachtens können wir die auch rausnehmen.
In dem punkt würde ist es gerne so handhaben das die Personen sich selbst raus nehmen. Wenn du magst kannst du lethexa mal fragen ob er sich raus nehmen möchte. Order ihm in CC nehmen so das er das schreiben kann.
Ich werde Status aktuell So auch nicht signieren!
Das Harte Datum 27.10 stört mich und ist viel zu nah an heute dran!
Auch das Datum hatten wir soweit besprochen. Da gab es keine Einwände. Es liegt 14 Tage nach Build zeit.
vg Tarek
Hi,
Danke für das viele Engagement, dass wieder in diese Firmware geflossen ist!
Ich habe die Diskussion zwischendurch immer wieder verfolgt und es scheint doch einige Bedenken zu geben. Ich lese heraus, dass es dabei nicht unbedingt Zweifel an der Codequalität sondern am Qualitätssicherungsprozess insgesamt gibt.
Es steht die Frage im Raum, wie wir uns vorab sicher sein können, dass durch das Update kein einziger Router offline geht. Das ist denke ich ein berechtigtes Anliegen. Insbesondere da wir uns mittlerweile in Größenordnungen bewegen, bei denen ein größerer Fehlerfall auch größere Auswirkungen auf unsere Reputation hat. Experimentiernetzwerk hin und oder.
Am Montag geht bspw. ein postalisches Informationsschreiben für die Freifunk Förderung in der Oldenburger Innenstadt an >500 ansässig Unternehmer. Dass im gleichen Schritt eine größere Umstellung in unserem Netz ansteht, macht mir durchaus Sorgen.
Ich möchte daher vorschlagen, dass wir die Firmware noch etwas reifen lassen. Dass wir uns intensiv Zeit nehmen uns mit dem Umstellungsprozess auseinanderzusetzen und auch mit der damit verbundenen Technik. Ich habe bspw. als einer der Signaturberechtigten von 802.11s bisher überhaupt keine Ahnung und noch nie damit gearbeitet. Auch weniger invasive Updatemethoden wie dem partiellen Update in einer einzelnen Hood haben wir glaube ich bisher nicht diskutiert.
Viele Grüße Clemens
Am Dienstag, 10. Oktober 2017, 23:45:19 CEST schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171010
- Gluon-Version: v2017.1.x
- Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7
- Download: https://firmware.ffnw.de/20171010
Folgende Gluon spezifischen Änderungen gab es unter anderen:
- Gluon basiert nun auf LEDE anstelle von OpenWRT welches stark veraltet
war/ist. Die LEDE basis von Gluon ist nun v17.01.3. Welches u.a. Stabilisierung-Verbesserungen, security fixes und einige Updates enthält. (Changelog findet sich hier ) v17.01 [0], v17.01.1 [1], v17.01.2 [2], v17.01.3 [3].
Der Kernel wurde von 3.18.x auf v4.4.89 geupgraded.
Das Gluon build system wurde vereinfacht und einige hacks die für OpenWRt
notwendig waren wurden entfernt.
das opkg repo enthält jetzt auch Architektur spezifischen Pakete.
Das deaktivieren von batman-adv auf einem Netzwerk Interface hat vorher
teilweise einen kernel crash verursacht. Z.B. während eines sysupgrade Prozesses. Diese Problem ist nun behoben (#680).
- Eine race condition im Netzwerk setup scripts konnte zu unvollständigen
Konfigurationen führen (#905). Der fix behebt außerdem das Hängenbleiben von WLAN und VPN losen Geräten.
- Einige Änderungen im WLAN stack von LEDE haben die Stabilität vom ath9k
Treiber verbessert (#605).
- Ein neues Feature ist der DNS cache für clients (#1000). Dieses kann das
Nutzer Erlebnis verbessern (#1000). Siehe dazu auch [4].
batman-adv wurde auf Version 2017.1 geupdated [5].
GCC 4.8 oder neuer wird jetzt zum bauen benötigt.
Support für tunneldigger mesh VPN
Ein bug in einigen batman-adv versions zuvor kann zu einer großen Anzahl
von management traffic führen. Das batman-adv multicast optimization wurde vorübergehend deaktiviert um das Problem zu umgehen. Multicast optimizations wird wieder eingeschaltet sobald das management traffic Problem behoben ist.
batman-adv gw_mode ist nun Upgrade fest (#1196). Das kann nützlich sein wenn man z.b. einen Gluon Router an einen Router mit DHCP hängt, muss der gw_mode gesetzt sein um batman-adv als server laufen zu lassen.
Es gibt jetzt die Möglichkeit die batman-adv Algorithmen (BATMAN IV or
BATMAN V) in der site.conf zu konfigurieren (#1185). BATMAN V ist nach wie vor nicht gut getestet. Diese Option ermöglichst es BATMAN V basierte test meshes aufzubauen.
- dnsmasq wurde auf v2.78 upgegraded um folgende bugs zu beheben:
CVE-2017-13704, CVE-2017-14491, CVE-2017-14492, CVE-2017-14493, CVE-2017-14494, 2017-CVE-14495 und 2017-CVE-14496 die wichtigsten fixes die oben genannt worden, beheben (remote code execution) in der DHCP Komponente von dnsmasq. Der DHCP ist nur im ConfigMode aktiv. Ein Angreifer kann memory Korruption und mögliche remote code execution erzwingen, indem er einen bösartig DNS Server anbietet und einen Gluon Router austrinkst so das dieser den bösartig DNS Server nutzt.
- Einige security Issues wurden in Paketen behoben die in der regel nicht
teil der Stock-Firmware von Gluon sind. Mit involviert sind u.a tcpdump, curl und mbedtls weiteres kann man hier einsehen [6]
- Das Filtern von multicast paketen zwischen dem mesh und local-node
interface wurde gefixed (#1230). Dieses Problem hatte verursacht das gluon-radvd router advertisement an lokale clients gesendet hatte wenn eine anfrage aus dem lokalen Netz kam.
- Es wird verhindert ein build tätigen wenn wir autoupdater mirror URLs
nicht mit http:// starten (9ab93992d1fc).
- Fix MAC Adressen für den TP-Link TL-WR1043ND v4 wenn Gluon auf der neueren
stock Firmware installiert wird (#1223).
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...3e2e72
Folgende Comunnity spezifischen Änderungen gab es: package repo:
- Das Paket "11s-switch" ist hinzugekommen. Diese sorgt dafür, das die
Router von IBSS (AD-HOC) auf 11s mesh wechseln. Der wechsel findet am 24.10.2017 statt.
- Das Paket "disable-11s" welches das versehentliche einschalten von
IEEE802.11s wieder rückgängig macht ist entfernt.
- Das Paket ffnw-config-mode-geo-location wurde aktualisiert, und nutzt
jetzt minified js.
Alle Pakete wurde von luci.model.uci auf simple-uci angepasst.
Die Default hood bssid wurde von 02:CA:FF:EE:BA:BF auf 02:00:0A:12:E0:00
korrigiert.
Das Paket hoodselectorctl wurde entfernt.
Das Paket nodewatcher2 wurde entfernt.
Das hoodselector upgrade script nutzt nun BSSIDs zur Identifikation der
hood, welche eindeutig ist, Anstelle des hoodnames.
Der hoodselector prüft im Radiolest Mode prüfe ob mesh on lan/wan an ist.
Der hoodselector nutzt nun kein scan dump mehr welchen Airtime gespart
hatte. diese funktion ist in LEDE nicht mehr vorhanden.
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170822... 20171010
siteconf repo:
- Ein paar patches die den umgeng mit IEEE802.11s in openWRT ermöglichen
wurden entfernt.
Das Modul netmon wurde entfernt.
fastd kann nun auch die crypt Methode 'null' was bedeutet das ein
unverschlüsselter Tunnel aufgebaut werden kann. Dies kann über den configMode eingestellt werden.
autoupdater good signatures level ist auf 5 gestiegen.
Geräte mit ATH10K sind in dieser version raus geflogen. Folgende Geräte erhalten das update nicht: MR1750 v1, v2; OM5P-AC v1, v2;
Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro.
- Die update Priorität wurde von 0 auf 2 erhöht. D.h. es dauert mindestens 2
tage bis alle Geräte das Update erhalten.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170822... 20171010
- Wichtiger Hinweis *
Es gibt ein Problem in allen Gluon Versionen vor 2016.2.6 welche die x86 Systeme betrifft. Diese verlieren ihre Konfiguration wenn diese auf Gluon 2017.1.x updaten. Ältere Firmware Versionen sollten vorher auf 20170822 [7] upgraden, bevor diese 20171005 installieren.
Ein anderes potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltes du vor den update auf 20171005 machen! Der Befehl für qemu wäre z.b. folgender:
qemu-img resize $IMAGE 273MB
Eine Firmware für die Geräte: MR1750 v1, v2; OM5P-AC v1, v2; Archer C5 v1; Archer C7 v2; UniFi AP AC Lite und UniFi AP AC Pro wird es am 24.10.2017 geben. Grund dafür ist das es nicht möglich ist, 11s und IBSS in einer Firmware zu bauen. Ein update dieser Geräte muss daher manuell erfolgen, wenn es sich um einen mesh only gerät handelt.
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: http://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße aus Spanien Tarek
[0] https://lede-project.org/releases/17.01/changelog-17.01.0-final [1] https://lede-project.org/releases/17.01/changelog-17.01.1 [2] https://lede-project.org/releases/17.01/changelog-17.01.2 [3] https://lede-project.org/releases/17.01/changelog-17.01.3 [4] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [5] https://www.open-mesh.org/news/78 [6] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-.... 01 [7] https://firmware.ffnw.de/20170822/
On 10/13/17 15:47, Clemens John via Dev wrote:
Hi,
Danke für das viele Engagement, dass wieder in diese Firmware geflossen ist!
Ich habe die Diskussion zwischendurch immer wieder verfolgt und es scheint doch einige Bedenken zu geben. Ich lese heraus, dass es dabei nicht unbedingt Zweifel an der Codequalität sondern am Qualitätssicherungsprozess insgesamt gibt.
Es steht die Frage im Raum, wie wir uns vorab sicher sein können, dass durch das Update kein einziger Router offline geht. Das ist denke ich ein berechtigtes Anliegen. Insbesondere da wir uns mittlerweile in Größenordnungen bewegen, bei denen ein größerer Fehlerfall auch größere Auswirkungen auf unsere Reputation hat. Experimentiernetzwerk hin und oder.
Das ist in der tat ein Punkt, wo ich auch angefangen habe drüber nach zu denken. Daher u.a. die Erhöhung der priority.
Mir ist aber noch keine wirklich schöne Idee gekommen wie wir vor ausrollen absolut sicher sein können das alles gut läuft...
Am Montag geht bspw. ein postalisches Informationsschreiben für die Freifunk Förderung in der Oldenburger Innenstadt an >500 ansässig Unternehmer. Dass im gleichen Schritt eine größere Umstellung in unserem Netz ansteht, macht mir durchaus Sorgen.
Ah cool.
Ich möchte daher vorschlagen, dass wir die Firmware noch etwas reifen lassen. Dass wir uns intensiv Zeit nehmen uns mit dem Umstellungsprozess auseinanderzusetzen und auch mit der damit verbundenen Technik. Ich habe bspw. als einer der Signaturberechtigten von 802.11s bisher überhaupt keine Ahnung und noch nie damit gearbeitet.
11s ändert nix. Es sorgt lediglich einfach dafür das wir mehr Hardware Support haben da es für die Hersteller einfacher zu implementieren ist.
Auch weniger invasive Updatemethoden wie dem partiellen Update in einer einzelnen Hood haben wir glaube ich bisher nicht diskutiert.
Dazu hast du ja schon eine Diskussionsmail eröffnet. Ich schreibe drauf später.
Also allgemein würde ich vorschlagen eine Firmware ohne den 11s-Switch zu bauen, da schon ein paar nicht ganz unkritische security issues behoben worden sind. Zudem sind einige wichtige Stabilisierende Änderungen gemacht worden die sowohl die Netz Qualität steigern sollten sowie zur Ausfallsicherheit beitragen. bsp. ist der lost carrier bug in den Ubiquity Geräten behoben, welcher dafür sorgte das die Geräte ihr ETH Interface verlieren und dieses erst nach einem Reboot wieder nutzbar ist. Auch der ATH9K Treiber ist deutlich performanter und stabiler geworden.
Den Switch auf 11s können wir auch später nach holen.
Schöne Grüße aus Frankreich :) Tarek
Moin
Von meinem iPhone gesendet
Am 13.10.2017 um 18:02 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 10/13/17 15:47, Clemens John via Dev wrote: Hi,
Danke für das viele Engagement, dass wieder in diese Firmware geflossen ist!
Ich habe die Diskussion zwischendurch immer wieder verfolgt und es scheint doch einige Bedenken zu geben. Ich lese heraus, dass es dabei nicht unbedingt Zweifel an der Codequalität sondern am Qualitätssicherungsprozess insgesamt gibt.
Es steht die Frage im Raum, wie wir uns vorab sicher sein können, dass durch das Update kein einziger Router offline geht. Das ist denke ich ein berechtigtes Anliegen. Insbesondere da wir uns mittlerweile in Größenordnungen bewegen, bei denen ein größerer Fehlerfall auch größere Auswirkungen auf unsere Reputation hat. Experimentiernetzwerk hin und oder.
Das ist in der tat ein Punkt, wo ich auch angefangen habe drüber nach zu denken. Daher u.a. die Erhöhung der priority.
Mir ist aber noch keine wirklich schöne Idee gekommen wie wir vor ausrollen absolut sicher sein können das alles gut läuft...
Am Montag geht bspw. ein postalisches Informationsschreiben für die Freifunk Förderung in der Oldenburger Innenstadt an >500 ansässig Unternehmer. Dass im gleichen Schritt eine größere Umstellung in unserem Netz ansteht, macht mir durchaus Sorgen.
Ah cool.
Ich möchte daher vorschlagen, dass wir die Firmware noch etwas reifen lassen. Dass wir uns intensiv Zeit nehmen uns mit dem Umstellungsprozess auseinanderzusetzen und auch mit der damit verbundenen Technik. Ich habe bspw. als einer der Signaturberechtigten von 802.11s bisher überhaupt keine Ahnung und noch nie damit gearbeitet.
11s ändert nix. Es sorgt lediglich einfach dafür das wir mehr Hardware Support haben da es für die Hersteller einfacher zu implementieren ist.
Auch weniger invasive Updatemethoden wie dem partiellen Update in einer einzelnen Hood haben wir glaube ich bisher nicht diskutiert.
Dazu hast du ja schon eine Diskussionsmail eröffnet. Ich schreibe drauf später.
Also allgemein würde ich vorschlagen eine Firmware ohne den 11s-Switch zu bauen, da schon ein paar nicht ganz unkritische security issues behoben worden sind. Zudem sind einige wichtige Stabilisierende Änderungen gemacht worden die sowohl die Netz Qualität steigern sollten sowie zur Ausfallsicherheit beitragen. bsp. ist der lost carrier bug in den Ubiquity Geräten behoben, welcher dafür sorgte das die Geräte ihr ETH Interface verlieren und dieses erst nach einem Reboot wieder nutzbar ist. Auch der ATH9K Treiber ist deutlich performanter und stabiler geworden.
Die Idee find ich auch besser Erst mal den Switch auf LEDE mit buggies und danach dann 11s Switch
Gruß
Johannes
Den Switch auf 11s können wir auch später nach holen.
Schöne Grüße aus Frankreich :) Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Clemens John -
Jan-Tarek Butt -
Johannes Rudolph -
lrnzo