Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20171206 * Gluon-Version: v2017.1.x * Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e * Download: https://firmware.ffnw.de/20171206
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.4. 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] v17.01.4 [4].
* Der Kernel wurde von 3.18.x auf v4.4.93 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 [5].
* batman-adv wurde auf Version 2017.1 geupdated [6].
* 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 [7]
* Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
* 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).
* Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
* Fix ein build issue in kmod-jool [8]
* Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
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.
* Shell banner wurde von openWRT auf LEDE gewechselt.
* 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 umgang 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 [11] upgraden, bevor diese 20171206 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 solltest du vor den update auf 20171206 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: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
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://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
signed. Da ich irgendwie das Gefühl habe, dass nicht genügend andere signs zusammen kommen werden, hier mal eine kleine Umfrage (unverbindlich, mir geht es nur um ein Stimmungsbild), was beim nächsten sign-request dazu führen würde, dass er genügend Anklang findet. Bitte wähle _eine_ der folgenden Varianten.
1. Die Änderungen an good_signatures _und_ priority werden zurückgenommen. 2. Die Änderung an good_signatures wird zurückgenommen. 3. Die Änderung an priority wird zurückgenommen.
imho würden wir mit den ersten beiden Varianten gegen unsere eigene Policy verstoßen, was die Anzahl der good_signatures betrifft, daher noch diese Variante:
4. Die Änderung an priority wird zurückgenommen und die Liste der signs wird soweit von Karteileichen befreit, dass good_signatures gemäß policy wieder auf 4 gesetzt werden kann. Wollte nicht irgendjemand (tm) die Leute anschreiben, die bisher noch nicht von ihrem Sign-Recht gebrauch gemacht haben?
oder gibt es andere Vorschläge, die dazu führen, das wir so langsam mal den Schritt ins gelobte LEDE-Land machen können?
LG Lorenz
Am 07.12.2017 um 11:29 schrieb Jan-Tarek Butt via Dev:
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171206
- Gluon-Version: v2017.1.x
- Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e
- Download: https://firmware.ffnw.de/20171206
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.4. 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] v17.01.4 [4].
Der Kernel wurde von 3.18.x auf v4.4.93 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 [5].
batman-adv wurde auf Version 2017.1 geupdated [6].
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 [7]
Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
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).
Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
Fix ein build issue in kmod-jool [8]
Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
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.
Shell banner wurde von openWRT auf LEDE gewechselt.
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 umgang 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 [11] upgraden, bevor diese 20171206 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 solltest du vor den update auf 20171206 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: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
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://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
Punkt 4 - mir sind die Signaturen eindeutig zu viele und das habe ich schon mehrfach gesagt.
Zusätzlich stört mich auch, dass die Update Time hochgesetzt wurde.
VG Stefan
Von meinem iPhone gesendet
Am 07.12.2017 um 14:42 schrieb lrnzo via Dev dev@lists.ffnw.de:
signed. Da ich irgendwie das Gefühl habe, dass nicht genügend andere signs zusammen kommen werden, hier mal eine kleine Umfrage (unverbindlich, mir geht es nur um ein Stimmungsbild), was beim nächsten sign-request dazu führen würde, dass er genügend Anklang findet. Bitte wähle _eine_ der folgenden Varianten.
- Die Änderungen an good_signatures _und_ priority werden zurückgenommen.
- Die Änderung an good_signatures wird zurückgenommen.
- Die Änderung an priority wird zurückgenommen.
imho würden wir mit den ersten beiden Varianten gegen unsere eigene Policy verstoßen, was die Anzahl der good_signatures betrifft, daher noch diese Variante:
- Die Änderung an priority wird zurückgenommen und die Liste der signs wird soweit von Karteileichen befreit, dass good_signatures gemäß policy wieder auf 4 gesetzt werden kann. Wollte nicht irgendjemand (tm) die Leute anschreiben, die bisher noch nicht von ihrem Sign-Recht gebrauch gemacht haben?
oder gibt es andere Vorschläge, die dazu führen, das wir so langsam mal den Schritt ins gelobte LEDE-Land machen können?
LG Lorenz
Am 07.12.2017 um 11:29 schrieb Jan-Tarek Butt via Dev: Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171206
- Gluon-Version: v2017.1.x
- Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e
- Download: https://firmware.ffnw.de/20171206
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.4. 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] v17.01.4 [4].
Der Kernel wurde von 3.18.x auf v4.4.93 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 [5].
batman-adv wurde auf Version 2017.1 geupdated [6].
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 [7]
Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
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).
Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
Fix ein build issue in kmod-jool [8]
Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
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.
Shell banner wurde von openWRT auf LEDE gewechselt.
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 umgang 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 [11] upgraden, bevor diese 20171206 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 solltest du vor den update auf 20171206 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: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
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://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Moin
Bei mir das gleiche wie bei Stefan
Wenn wir genug Leute hätten die signieren würden ernsthaft dann hätten wir schon länger die signs für die LEDE Version.... auch ohne die Signatur von Stefan und mir
Gerne können wir Updates hoodweit ausrollen aber das hochsetzen der priority versteh ich halt nicht warum wir das auf 2 Tage strecken sollten
@Lorenz Danke für deine Nachricht und den Anstoß der Diskussion
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.12.2017 um 14:52 schrieb Stefan Dunkel via Dev dev@lists.ffnw.de:
Hi,
Punkt 4 - mir sind die Signaturen eindeutig zu viele und das habe ich schon mehrfach gesagt.
Zusätzlich stört mich auch, dass die Update Time hochgesetzt wurde.
VG Stefan
Von meinem iPhone gesendet
Am 07.12.2017 um 14:42 schrieb lrnzo via Dev dev@lists.ffnw.de:
signed. Da ich irgendwie das Gefühl habe, dass nicht genügend andere signs zusammen kommen werden, hier mal eine kleine Umfrage (unverbindlich, mir geht es nur um ein Stimmungsbild), was beim nächsten sign-request dazu führen würde, dass er genügend Anklang findet. Bitte wähle _eine_ der folgenden Varianten.
- Die Änderungen an good_signatures _und_ priority werden zurückgenommen.
- Die Änderung an good_signatures wird zurückgenommen.
- Die Änderung an priority wird zurückgenommen.
imho würden wir mit den ersten beiden Varianten gegen unsere eigene Policy verstoßen, was die Anzahl der good_signatures betrifft, daher noch diese Variante:
- Die Änderung an priority wird zurückgenommen und die Liste der signs wird soweit von Karteileichen befreit, dass good_signatures gemäß policy wieder auf 4 gesetzt werden kann. Wollte nicht irgendjemand (tm) die Leute anschreiben, die bisher noch nicht von ihrem Sign-Recht gebrauch gemacht haben?
oder gibt es andere Vorschläge, die dazu führen, das wir so langsam mal den Schritt ins gelobte LEDE-Land machen können?
LG Lorenz
Am 07.12.2017 um 11:29 schrieb Jan-Tarek Butt via Dev: Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171206
- Gluon-Version: v2017.1.x
- Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e
- Download: https://firmware.ffnw.de/20171206
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.4. 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] v17.01.4 [4].
Der Kernel wurde von 3.18.x auf v4.4.93 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 [5].
batman-adv wurde auf Version 2017.1 geupdated [6].
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 [7]
Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
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).
Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
Fix ein build issue in kmod-jool [8]
Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
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.
Shell banner wurde von openWRT auf LEDE gewechselt.
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 umgang 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 [11] upgraden, bevor diese 20171206 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 solltest du vor den update auf 20171206 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: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
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://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
ist es denn so, dass alle 10 Leute, deren pubkey sich in der site.conf finden, auch regelmäßig auf dieser Mailingliste mitlesen und mithin notiz von sign-requests nehmen können? wie ist es zB bei lethexa, kann der- oder diejenige bitte einmal ping machen?
LG Lorenz
Am 07.12.2017 um 15:14 schrieb Johannes Rudolph via Dev:
Moin
Bei mir das gleiche wie bei Stefan
Wenn wir genug Leute hätten die signieren würden ernsthaft dann hätten wir schon länger die signs für die LEDE Version.... auch ohne die Signatur von Stefan und mir
Gerne können wir Updates hoodweit ausrollen aber das hochsetzen der priority versteh ich halt nicht warum wir das auf 2 Tage strecken sollten
@Lorenz Danke für deine Nachricht und den Anstoß der Diskussion
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.12.2017 um 14:52 schrieb Stefan Dunkel via Dev dev@lists.ffnw.de:
Hi,
Punkt 4 - mir sind die Signaturen eindeutig zu viele und das habe ich schon mehrfach gesagt.
Zusätzlich stört mich auch, dass die Update Time hochgesetzt wurde.
VG Stefan
Von meinem iPhone gesendet
Am 07.12.2017 um 14:42 schrieb lrnzo via Dev dev@lists.ffnw.de:
signed. Da ich irgendwie das Gefühl habe, dass nicht genügend andere signs zusammen kommen werden, hier mal eine kleine Umfrage (unverbindlich, mir geht es nur um ein Stimmungsbild), was beim nächsten sign-request dazu führen würde, dass er genügend Anklang findet. Bitte wähle _eine_ der folgenden Varianten.
- Die Änderungen an good_signatures _und_ priority werden zurückgenommen.
- Die Änderung an good_signatures wird zurückgenommen.
- Die Änderung an priority wird zurückgenommen.
imho würden wir mit den ersten beiden Varianten gegen unsere eigene Policy verstoßen, was die Anzahl der good_signatures betrifft, daher noch diese Variante:
- Die Änderung an priority wird zurückgenommen und die Liste der signs wird soweit von Karteileichen befreit, dass good_signatures gemäß policy wieder auf 4 gesetzt werden kann. Wollte nicht irgendjemand (tm) die Leute anschreiben, die bisher noch nicht von ihrem Sign-Recht gebrauch gemacht haben?
oder gibt es andere Vorschläge, die dazu führen, das wir so langsam mal den Schritt ins gelobte LEDE-Land machen können?
LG Lorenz
Am 07.12.2017 um 11:29 schrieb Jan-Tarek Butt via Dev: Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
- Firmware-Version: 20171206
- Gluon-Version: v2017.1.x
- Commit ID: 2ae74fe737a45e589f85ace098fa8466dfb7927e
- Download: https://firmware.ffnw.de/20171206
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.4. 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] v17.01.4 [4].
Der Kernel wurde von 3.18.x auf v4.4.93 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 [5].
batman-adv wurde auf Version 2017.1 geupdated [6].
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 [7]
Fixes für KRACK sind enthalten welches für wenige spezielle gluon Setups relevant ist.
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).
Fix DNS Auflösung für den mesh VPN (fastd / tunneldigger) auf ARM-basierten targets (#1245)
Fix ein build issue in kmod-jool [8]
Fix enabling/disabling PoE Passthrough in site.conf oder in den advanced settings [9], [10]
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/d722c2...2ae74f
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.
Shell banner wurde von openWRT auf LEDE gewechselt.
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 umgang 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 [11] upgraden, bevor diese 20171206 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 solltest du vor den update auf 20171206 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: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signiere...
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://lede-project.org/releases/17.01/changelog-17.01.4 [5] https://gluon.readthedocs.io/en/v2017.1.x/features/dns-cache.html [6] https://www.open-mesh.org/news/78 [7] https://git.lede-project.org/?p=source.git%3Ba=shortlog%3Bh=refs/heads/lede-... [8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9df... [9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd609... [10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69f... [11] https://firmware.ffnw.de/20170822/
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
Punkt 4 - mir sind die Signaturen eindeutig zu viele und das habe ich schon mehrfach gesagt.
Ich würde hier gerne nochmal auf eikes Vorschlag mit den Thread "Signaturen" zurück greifen und
für eine feste Anzahl an Signaturen stimmen. Mein Vorschlag wäre allerdings 4 anstelle von 5 Signaturen vorschlagen.
Die Diskussion scheint irgendwie untergegangen zu sein. Eike, Clemens und fkr hatten dafür gestimmt.
--- eikes Mail ---
Ich habe den Sinn einer prozentualen Regelung nie verstanden. Warum sagen wir nicht einfach: 5* müssen signieren. Dann können auch problemlos die Signaturen derjenigen, die nicht so häufig signen, drin bleiben und je größer der Pool derjenigen, die zwar kompetent und grundsätzlich engagiert genug zum testen und signen sind, wäre ausreichend groß, um jederzeit und unabhängig von individuellem Zeitmangel, ausreichend Signs zu erhalten.
Die Extremfälle, dass zb bei sehr wenigen hinterlegten Keys zwei Leute die Firmware alleine durchwinken können und bei sehr vielen hinterlegten Keys 3 Wochen hinter ausreichend signs hinterhergebettelt werden muss, fallen damit dann automatisch weg.
Viele Grüße, Eike
* die genaue Anzahl sollte dann nochmal diskutiert werden
--- ende ---
Zusätzlich stört mich auch, dass die Update Time hochgesetzt wurde.
Genau darüber haben wir doch im thread "status v2017.1.x" geschrieben. Warum wird denn da nicht entsprechend drauf reagiert?
Schöne Grüße Tarek Tarek
Hi,
Zusätzlich stört mich auch, dass die Update Time hochgesetzt wurde.
Genau darüber haben wir doch im thread "status v2017.1.x" geschrieben. Warum wird denn da nicht entsprechend drauf reagiert?
Ich ziehe meinen Vorschlag über die Erhöhung der GLUON_PRIORITY zurück, um hier mal ein wenig voran zu kommen :)
Bleibt nur noch die Klärung der Anzahl der Signaturen.
Schöne Grüße Tarek
Moin
Also grundsätzlich ist die Idee ja auch gut mit der Hälfte der Leute, aber wie wir in den letzten Wochen gesehen haben aktuell nicht praktikabel.
Wenn alle „Entwickler“ bzw. Signierberechtigten „aktiv“ dabei wären was die Firmware angeht dann wäre die Firmware schon lange ausgerollt, auch wenn sich Johannes und Stefan gerade „weigern“ die aktuelle Variante zu signieren aus bereits benannten Gründen.
Allerdings ist ja quasi gerade Stillstand statt Fortschritt obwohl wir auf dem Papier genug Leute hätten, also sollten wir nun schauen wie wir das Problem lösen...
Also entweder die Regel neu definieren oder „inaktive“ Leute die Signieren dürften das aber noch nie getan haben in ihrem Leben aus der Liste aktuell zu streichen, wenn sich da die Umstände ändern sollten können sie ja gerne wieder eingetragen werden.
Gruß
Johannes
Von meinem iPhone gesendet
Am 09.12.2017 um 13:29 schrieb lrnzo via Dev dev@lists.ffnw.de:
lrnzo ist auch dafür
Am 09.12.2017 um 13:18 schrieb Jan-Tarek Butt via Dev: Die Diskussion scheint irgendwie untergegangen zu sein. Eike, Clemens und fkr hatten dafür gestimmt.
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
bevor wir jetzt den Rotstift schwingen: @Lethexa bitte gib mal ein Lebenszeichen von dir, damit wir wissen, dass du diese Mailingliste noch liest.
Hat irgendwer eine Mailadresse von ihm/ihr? oder kann ihn/sie auf irgendeinem anderen Kanal erreichen?
LG Lorenz
Am 09.12.2017 um 14:00 schrieb Johannes Rudolph via Dev:
Moin
Also grundsätzlich ist die Idee ja auch gut mit der Hälfte der Leute, aber wie wir in den letzten Wochen gesehen haben aktuell nicht praktikabel.
Wenn alle „Entwickler“ bzw. Signierberechtigten „aktiv“ dabei wären was die Firmware angeht dann wäre die Firmware schon lange ausgerollt, auch wenn sich Johannes und Stefan gerade „weigern“ die aktuelle Variante zu signieren aus bereits benannten Gründen.
Allerdings ist ja quasi gerade Stillstand statt Fortschritt obwohl wir auf dem Papier genug Leute hätten, also sollten wir nun schauen wie wir das Problem lösen...
Also entweder die Regel neu definieren oder „inaktive“ Leute die Signieren dürften das aber noch nie getan haben in ihrem Leben aus der Liste aktuell zu streichen, wenn sich da die Umstände ändern sollten können sie ja gerne wieder eingetragen werden.
Gruß
Johannes
Von meinem iPhone gesendet
Am 09.12.2017 um 13:29 schrieb lrnzo via Dev dev@lists.ffnw.de:
lrnzo ist auch dafür
Am 09.12.2017 um 13:18 schrieb Jan-Tarek Butt via Dev: Die Diskussion scheint irgendwie untergegangen zu sein. Eike, Clemens und fkr hatten dafür gestimmt.
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Ok, dann lasst uns mal darüber abstimmen :)
https://wiki.ffnw.de/Diskussion:Firmware/Releaseprozess
LG Lorenz
Am 09.12.2017 um 13:18 schrieb Jan-Tarek Butt via Dev:
Hi,
Punkt 4 - mir sind die Signaturen eindeutig zu viele und das habe ich schon mehrfach gesagt.
Ich würde hier gerne nochmal auf eikes Vorschlag mit den Thread "Signaturen" zurück greifen und
für eine feste Anzahl an Signaturen stimmen. Mein Vorschlag wäre allerdings 4 anstelle von 5 Signaturen vorschlagen.
Die Diskussion scheint irgendwie untergegangen zu sein. Eike, Clemens und fkr hatten dafür gestimmt.
--- eikes Mail ---
Ich habe den Sinn einer prozentualen Regelung nie verstanden. Warum sagen wir nicht einfach: 5* müssen signieren. Dann können auch problemlos die Signaturen derjenigen, die nicht so häufig signen, drin bleiben und je größer der Pool derjenigen, die zwar kompetent und grundsätzlich engagiert genug zum testen und signen sind, wäre ausreichend groß, um jederzeit und unabhängig von individuellem Zeitmangel, ausreichend Signs zu erhalten.
Die Extremfälle, dass zb bei sehr wenigen hinterlegten Keys zwei Leute die Firmware alleine durchwinken können und bei sehr vielen hinterlegten Keys 3 Wochen hinter ausreichend signs hinterhergebettelt werden muss, fallen damit dann automatisch weg.
Viele Grüße, Eike
- die genaue Anzahl sollte dann nochmal diskutiert werden
--- ende ---
Zusätzlich stört mich auch, dass die Update Time hochgesetzt wurde.
Genau darüber haben wir doch im thread "status v2017.1.x" geschrieben. Warum wird denn da nicht entsprechend drauf reagiert?
Schöne Grüße Tarek Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
So nun sind wir wieder bei 4 Signaturen die nötig sind.
Ich baue ne neue Firmware.
Schöne Grüße Tarek
läuft das schon? in der site.mk steht immerhin GLUON_PRIORITY ?= 0, aber in der site.conf immernoch good_signatures = 5. Ja, HEAD steht auf 20171211.
LG Lorenz
Am 11.12.2017 um 14:36 schrieb Jan-Tarek Butt via Dev:
Hi,
So nun sind wir wieder bei 4 Signaturen die nötig sind.
Ich baue ne neue Firmware.
Schöne Grüße Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
On 12/11/17 11:28, lrnzo via Dev wrote:
Ok, dann lasst uns mal darüber abstimmen :)
https://wiki.ffnw.de/Diskussion:Firmware/Releaseprozess
LG Lorenz
Da bisher einstimmig für die Änderung gestimmt wurde, habe ich diese in der Dokumentation der Firmware ergänzt:
https://wiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Danke, das hatte ich vergessen.
Am 20.12.2017 um 01:47 schrieb Jan-Tarek Butt via Dev:
On 12/11/17 11:28, lrnzo via Dev wrote:
Ok, dann lasst uns mal darüber abstimmen :)
https://wiki.ffnw.de/Diskussion:Firmware/Releaseprozess
LG Lorenz
Da bisher einstimmig für die Änderung gestimmt wurde, habe ich diese in der Dokumentation der Firmware ergänzt:
https://wiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de