Moin Moin leute, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20171014 * Gluon-Version: v2017.1.x * Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7 * Download: https://firmware.ffnw.de/20171014 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 "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 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. * 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 20171014 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 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 Frankreich 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;a=shortlog;h=refs/heads/lede-17.0... [7] https://firmware.ffnw.de/20170822/
Hi, ich wäre dafür, das wir zukünftig solche Änderungen per Merge Request und die Vote Funktion im GitLab abstimmen. Es wurde mal angesprochen, jedoch nie entschieden. Von meinem iPhone gesendet
Am 15.10.2017 um 13:45 schrieb Johannes Rudolph via Dev <dev@lists.ffnw.de>:
Moin
Am 15.10.2017 um 12:14 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
* 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.
Wann haben wir das den diskutiert und besprochen finde dazu nix _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am 15.10.2017 um 15:29 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Wir arbeiten über MRs
Also wenn ich mir die Historie so anschauen im Site.conf repo dann sieht das aber ganz und gar nicht da nach aus! Und wenn du mal einen Merge Request erstellt hast hast du den selber gemerged... Wenn du einen erstellt hast dann mach bitte eine eMail auf der Mailingliste und stelle diesen zur Abstimmung/CodeReview oder ähnliches und geb Leuten Zeit darauf zu reagieren! Also du hast das Thema mal angesprochen Ja aber eine eindeutige Entscheidungsfindung gab es nie
On 10/15/17 17:35, Johannes Rudolph via Dev wrote:
Am 15.10.2017 um 15:29 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Wir arbeiten über MRs
Also wenn ich mir die Historie so anschauen im Site.conf repo dann sieht das aber ganz und gar nicht da nach aus!
Der MR für v2017.1.x war über ein Monat offen.
Und wenn du mal einen Merge Request erstellt hast hast du den selber gemerged...
Ja, wenn der MR länger als eine Woche ohne Einwände offen ist merge ich ihn.
Wenn du einen erstellt hast dann mach bitte eine eMail auf der Mailingliste und stelle diesen zur Abstimmung/CodeReview oder ähnliches und geb Leuten Zeit darauf zu reagieren!
Da bin ich gegen. Du hast hast jederzeit die Möglichkeit den Code ein zu sehen und spätestens bei einem SignRequest Einwände zu äußern. Eine Alternative die ich sehr bevorzugen würde, wäre ein Patchworker einzureichen. Dann arbeiten wir nur über Patches auf der ML da würde ich die MR Funktion allerdings im git deaktivieren.
Also du hast das Thema mal angesprochen Ja aber eine eindeutige Entscheidungsfindung gab es nie
Das Thema stand Lange auf der ML zur Diskussion wenn keine Einwände kommen ist davon auszugehen das alle damit einverstanden sind. vg Tarek
Hallo,
Am 15.10.2017 um 12:14 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
* 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.
Wann haben wir das den diskutiert und besprochen finde dazu nix
Das Thema war in dem Thread mit dem Betreff "status v2017.1.x" Sonnige Grüße aus Frankreich :) Tarek
habe diese firmware [1] hier mal auf nen futro210 installiert. btw: warum muss das entpackte image >250 MB groß sein, wenn ich die Partitionen auch auf 6 bzw 20 MB verkleinern kann? Mein futro hier hat nämlich nur eine ganz kleine CF-Karte drin. das eigentliche Problem: der config mode "geht nicht". genauer es ist kein interface br-setup definiert. Ich komme gerade nur auf das Gerät, weil ich per lokaler shell (ja, bildschirm + Tastatur angeschlossen) "ifconfig lan up" gemacht habe und dann per ssh+linklocal rauf kam. so sieht das dann aus: ---------------------8<--------------------- root@LEDE:~# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd0d:4f4d:7cbd::/48' config interface 'lan' option type 'bridge' option ifname 'eth0' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' --------------------->8--------------------- mehr nicht. [1] http://firmware.ffnw.de/20171014/gluon-ffnw-20171014-x86-generic.img.gz kann das jemand überprüfen? Am 15.10.2017 um 12:14 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20171014 * Gluon-Version: v2017.1.x * Commit ID: 3e2e72729f43aff4dcbc8da63336990875929cd7 * Download: https://firmware.ffnw.de/20171014
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 "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 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.
* 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 20171014 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
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 Frankreich 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;a=shortlog;h=refs/heads/lede-17.0... [7] https://firmware.ffnw.de/20170822/
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 10/18/17 23:16, lrnzo via Dev wrote:
habe diese firmware [1] hier mal auf nen futro210 installiert. btw: warum muss das entpackte image >250 MB groß sein, wenn ich die Partitionen auch auf 6 bzw 20 MB verkleinern kann? Mein futro hier hat nämlich nur eine ganz kleine CF-Karte drin.
Die Images wurden auf eine etwas sinnvollere Basisgröße aufgerundet, nachdem vor einiger Zeit die Kernel-Partition zu voll war. Die Größe des rootfs hängt damit zusammen, dass die maximale Größe, auf die die Partition mit resize2fs vergrößert werden kann, von der ursprünglichen Größe abhängt. Mehr kann ich dazu auch nicht sagen, da müsste ich dann auch auf der LEDE liste nachfragen.
das eigentliche Problem: der config mode "geht nicht". genauer es ist kein interface br-setup definiert. Ich komme gerade nur auf das Gerät, weil ich per lokaler shell (ja, bildschirm + Tastatur angeschlossen) "ifconfig lan up" gemacht habe und dann per ssh+linklocal rauf kam. so sieht das dann aus:
---------------------8<--------------------- root@LEDE:~# cat /etc/config/network
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0'
config globals 'globals' option ula_prefix 'fd0d:4f4d:7cbd::/48'
config interface 'lan' option type 'bridge' option ifname 'eth0' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' --------------------->8---------------------
mehr nicht.
scheinbar gibt es kein eth0 Interface. Grund könnte ein fehlender Treiber sein. vg Tarek
Hi,
das eigentliche Problem: der config mode "geht nicht". genauer es ist kein interface br-setup definiert. Ich komme gerade nur auf das Gerät, weil ich per lokaler shell (ja, bildschirm + Tastatur angeschlossen) "ifconfig lan up" gemacht habe und dann per ssh+linklocal rauf kam. so sieht das dann aus:
---------------------8<--------------------- root@LEDE:~# cat /etc/config/network
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0'
config globals 'globals' option ula_prefix 'fd0d:4f4d:7cbd::/48'
config interface 'lan' option type 'bridge' option ifname 'eth0' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' --------------------->8---------------------
mehr nicht.
scheinbar gibt es kein eth0 Interface. Grund könnte ein fehlender Treiber sein.
Ich gehe mal davon aus das es sich um einen futro a210. Dieser müsste folgende eth HW haben: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Ich hab zu der HW jetzt nur spontan folgendes gefunden(wenn es diese ist): https://bugs.lede-project.org/index.php?do=details&task_id=629 vg Tarek
Hi zusammen, ich wollte einmal an den sign request erinnern. Falls ihr offene fragen habt würde ich sehr gerne versuchen diese zu beantworten. vg Tarek
wolltest du den SR nicht zurück ziehen, u.a. wegen des bugs bei den ARM-Targets? Mittlerweile gibt es auch gluon 2017.1.4. wenn die jemand baut, könnte man damit schon mal rumtesten ... LG Lorenz Am 31.10.2017 um 15:28 schrieb Jan-Tarek Butt via Dev:
Hi zusammen,
ich wollte einmal an den sign request erinnern.
Falls ihr offene fragen habt würde ich sehr gerne versuchen diese zu beantworten.
vg Tarek
_______________________________________________ Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 11/26/17 12:38, lrnzo via Dev wrote:
wolltest du den SR nicht zurück ziehen, u.a. wegen des bugs bei den ARM-Targets? Mittlerweile gibt es auch gluon 2017.1.4. wenn die jemand baut, könnte man damit schon mal rumtesten ...
Jo danke dir, der Sign request ist nun zurück gezogen. Grund ist ein bug im Arm Target wie Lorenz es schon geschrieben hatte. Eine Neue Firmware habe ich gerade angestoßen. Schöne Grüße :) Tarek
Teilnehmer (4)
-
Jan-Tarek Butt -
Johannes Rudolph -
lrnzo -
Stefan Dunkel