Moin Sebastian,
Ich hab die mail mal auf die dev liste verschoben.
Ich hoffe das ist ok für dich?
> ich teste die neue Firmware etwas mit, verschiedene Hardware hab ich
> getestet, derzeit bin ich beim Raspi 2 angekommen, hier scheint es keine
> FW zu geben?
>
> root@FF-IBB-KoS-Raspi-Offloader:~# autoupdater -f
> Downloading 'http://autoupdate-lede.ffnw/l2tp/stable/stable.manifest'
> Connecting to 2a01:4f8:150:50a2::107:80
> Writing to stdout
> - 100% |*******************************| 62127
> 0:00:00 ETA
> Download completed (62127 bytes)
> No matching firmware found (model raspberry-pi-2-model-b-rev-1.1)
> No usable mirror found.
Bei der brcm2708-bcm2708 sowie der brcm2708-bcm2709 Architektur sind die
RPIs. Hier ist bereits bekannt das die RPIs unterschiedliche Hardware
Plattformen zurück liefern. Das Problem wird auf der LEDE dev liste bereits
diskutiert.
ich hab einen MR erstellt:
https://github.com/freifunk-gluon/gluon/pull/1276
Dieser ist natürlich keine Dauerlösung sondern Erstmal nen schneller hot-fix
Ich packe deine o.g. Architektur dazu.
vg
Tarek
Hallo zusammen,
im Rahmen eines zentalen batman-adv Updates werden wir morgen,
21.12.2017 in der Zeit zwischen 10 und 12 Uhr Updates auf allen Gateways
ausrollen.
Es kann hier zu Problemen im Freifunk Netz (IP-Vergabe, Tunnelaufbau
etc) kommen.
Viele Grüße,
Stefan
Hi zusammen,
Ich habe gerade mal das batman-adv-dkms und batctl Paket geupgradet:
batman-adv-dkms von v2017.0.1 auf v2017.3:
Changelog:
* support latest kernels (3.2 - 4.14)
* bridge loop avoidance improvements for various corner cases
* reduction of maximum fragment size
* coding style cleanups and refactoring
* avoid bridge loop detection mac addresses in translation tables
* bugs squashed:
- fix rx packet/bytes stats on local DAT ARP reply
- fix TT sync flag inconsistencies
- ignore invalid throughput values from wifi interfaces
batctl von 2017.0 auf batctl von 2017.3
* coding style cleanups and refactoring
* bugs squashed:
- Fix error messages on traceroute send failures
Schöne grüße
Tarek
Hallo zusammen,
ich möchte diesen TODO Punkt gerne streichen daher stoße ich das ganze noch mal an.
Ich favorisiere die Variante, dass wir 11s und AdHoc eine begrenzte Zeit noch einmal parallel aktivieren und dann AdHoc deaktivieren mit einem zweiten Firmwareupdate.
Die letzten beiden Updates haben gezeigt, dass unser Firmware Update innerhalb von nur wenigen Stunden komplett durch ist.
Ich würde als „Übergangsfrist“ eine Woche definiert wollen, in der beides Aktiv ist. Die beiden Firmwareversionen sollten wir parallel signieren um dann schnell handeln zu können und dieses ausrollen zu können.
Ebenso würde ih noch mal auf dem Blog drauf hinweisen und allen Leuten anraten, den Autoupdater zu aktivieren.
Gruß
Johannes
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_signier…
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;a=shortlog;h=refs/heads/lede-17.…
[8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9d…
[9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd60…
[10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69…
[11] https://firmware.ffnw.de/20170822/
Hallo, folgendes Problem,
nachdem eine proxmox vm auf 1GB vergrößert und per sysupgrade auf 20171211 gebracht wurde, hängt sie in eine Rebootschleife. Aus dem, as an einem in der proxmox-konsole verbeifliegt, konnte Sebastian folgdendes lesen:
Kernel offest disabled
kennt das wer? wo liegt das Problem?
LG Lorenz
Hallo Leute,
bekanntlich sorgen ja folgende Zeilen in der /etc/config/network dafür, dass das Interface br-wan nicht automatisch Teil der batman-bridge wird
config interface 'mesh_wan'
option ifname 'br-wan'
option transitive '1'
option fixed_mtu '1'
option proto 'gluon_mesh'
option auto '0'
allerdings ist Thomas und mir heute auf einigen offloadern aufgefallen, dass trotzdem "br-wan: active" aufgelistet wird, wenn man mit "batctl if" die Interfaces in der batman-bridge abfragt. und gemesht wird darüber auch. Aufgefallen ist das, weil es einen hoodkurzschluss zwischen Bad-Iburg und LK-OS gab, aber das nur nebenbei.
logread sagt dazu:
Thu Nov 16 19:22:02 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now
Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934431] batman_adv: bat0: Adding interface: br-wan
Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.934718] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Thu Nov 16 19:22:02 2017 kern.info kernel: [ 107.935802] batman_adv: bat0: Interface activated: br-wan
ich habe dann mal meine parallel-ssh-superkräfte eingesetzt und gesehen, dass auf folgenden Routern zwar "network.mesh_wan.auto='0'" gesetzt, aber trotzdem "br-wan: active" ist.
Butjadingen-Deichgraf-A20
Butjadingen-Deichgraf-A26
Butjadingen-Deichgraf-A8
Butjadingen-Deichgraf-B1
Butjadingen-Deichgraf-B12
Butjadingen-Deichgraf-B20
Butjadingen-Deichgraf-B22
Butjadingen-Deichgraf-C3
Butjadingen-Deichgraf-D4
Butjadingen-Deichgraf-Schwimmbad
Butjadingen-FaM-Butjadingerstr.-51-4
Butjadingen-FaM-Butjadingerstr.-51-5
Butjadingen-FaM-Butjadingerstr.-51-8
Butjadingen-Familien-Aparthotel-Strandhof-1
Butjadingen-Familien-Aparthotel-Strandhof-2
Butjadingen-FaM-Langlütjenring-1
Butjadingen-FaM-Langlütjenring-27
Butjadingen-FaM-Langlütjenring-29
Butjadingen-FaM-Langlütjenring-3
Butjadingen-FaM-Marschenring-14
Butjadingen-FaM-Marschenring-15
Butjadingen-FaM-Marschenring-19
Butjadingen-FaM-Marschenring-20
Butjadingen-FaM-Marschenring-37
Butjadingen-FaM-Marschenring-42
Butjadingen-FaM-Marschenring-48
Butjadingen-FaM-Marschenring-49
Butjadingen-FaM-Marschenring-53
Butjadingen-FaM-Marschenring-63
Butjadingen-FaM-Wattenring-1
Butjadingen-FaM-Wattenring-13
Butjadingen-FaM-Wattenring-16
Butjadingen-FaM-Wattenring-17
Butjadingen-FaM-Wattenring-2
Butjadingen-FaM-Wattenring-20
Butjadingen-FaM-Wattenring-24
Butjadingen-FaM-Wattenring-27
Butjadingen-FaM-Wattenring-28
Butjadingen-FaM-Wattenring-30
Butjadingen-FaM-Wattenring-35
Butjadingen-FaM-Wattenring-36
Butjadingen-FaM-Wattenring-39
Butjadingen-FaM-Wattenring-42
Butjadingen-FaM-Wattenring-43
Butjadingen-FaM-Wattenring-47
Butjadingen-FaM-Wattenring-5
Butjadingen-FaM-Wattenring-6
Butjadingen-FaM-Wattenring-8a
Butjadingen-FaM-Wattenring-9
Butjadingen-Ferienwohnung-1
Butjadingen-Ferienwohnung-Schild
Butjadingen-Ferienwohnung-Schild-2
Butjadingen-Ferienwohnung-Schild-4
Butjadingen-Ferienwohnung-Schild-5
Butjadingen-Ferienwohnung-Schild-6
Butjadingen-Ferienwohnung-Schild-7
Butjadingen-Freifunk-Test
Butjadingen-Gulfshof1
Butjadingen-HofvonOldenburg
Butjadingen-HofvonOldenburg1
Butjadingen-WaReDi
Ferienwohnung-Frings-3
Ferienwohnung-Frings-4
FF-IBB-HK-Offloader
FF-IBB-SchWeg-Offloader
FF-IBB-STADT-Offloader05
ffnw-LOHNetz_Braegeler_Ring_15_01
ffnw-LOHNetz_Falkenweg_21
ffnw-LOHNetz_Feuerwehr-Brockdorf_01-NDS
ffnw-LOHNetz_Gewerbering_14-15_01
ffnw-LOHNetz_Hamberger_Pickerweg_42_01
ffnw-LOHNetz_Marktstrasse_11_01
ffnw-LOHNetz_Marktstrasse_30_01
ffnw-LOHNetz_Rathaus_01
ffnw-LOHNetz_Schuetzenfest-2017-VPN
FF-OL-Bültmann-uplink
ff-os-ameos-Gertrudenring12-nds1266
ff-os-ameos-Gertrudenring12-nds1267
ff-os-ameos-Gertrudenring12-nds1268
ff-os-ameos-Gertrudenring12-nds1269
ff-os-ameos-Gertrudenring13-nds1270
ff-os-ameos-Gertrudenring13-nds1271
ff-os-ameos-Gertrudenring13-nds1272
ff-os-ameos-Gertrudenring2-nds1253
ff-os-ameos-Gertrudenring2-nds1254
ff-os-ameos-Gertrudenring3-nds1255
ff-os-ameos-Gertrudenring4-nds1257
ff-os-ameos-Gertrudenring4-nds1258
ff-os-ameos-Gertrudenring5-nds1259
ff-os-ameos-Gertrudenring5-nds1260
ff-os-ameos-Gertrudenring5-nds1261
ff-os-ameos-Gertrudenring7-nds1262
ff-os-ameos-Gertrudenring7-nds1263
ff-os-ameos-Gertrudenring9-nds1264
ff-os-ameos-Gertrudenring9-nds1265
ff-os-ameos-Knollstrasse27-nds1274
ff-os-ameos-Knollstrasse29-nds1275
ff-os-ameos-Knollstrasse29-nds1276
ff-os-ameos-Knollstrasse31-A2-1r-nds1277
ff-os-ameos-Knollstrasse31-A3-2r-nds1278
ff-os-ameos-Knollstrasse31d-nds1906
ff-os-ameos-Knollstrasse31-Lecker-nds1905
ff-os-ameos-Knollstrasse31-Lift-nds1917
ff-os-ameos-Knollstrasse31-S2-4r-nds1281
ff-os-ameos-Knollstrasse31-S5-nds1283
ff-os-ameos-Knollstrasse31-VER-nds1286
ff-os-ameos-Knollstrasse86a-P1-nds1914
ff-os-ameos-Knollstrasse86-G1-nds1909
ff-os-ameos-Knollstrasse86-G2-nds1910
ff-os-ameos-Knollstrasse86-G3-nds1911
ff-os-ameos-Knollstrasse86-IAG-nds1908
ff-os-ameos-Knollstrasse86-PSM1-nds1912
FF-OS-Bramscher-Str-159-Indoor
FF-OS-Fokus-eV
FF-OS-Peiner5-0R
FF-OS-Trattoria-Grani-Ost
Was kann der Grund sein? Kann das jemand bei sich bestätigen? Auch für LEDE?
LG Lorenz
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 20171126
* Gluon-Version: v2017.1.x
* Commit ID: 83bb7ef820d37b818a169bb910b17dc26cccd288
* Download: https://firmware.ffnw.de/20171126
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...83bb7e
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 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 20171126 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 20171126 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_signier…
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;a=shortlog;h=refs/heads/lede-17.…
[8] https://github.com/freifunk-gluon/gluon/commit/06842728233a39784c437767eb9d…
[9] https://github.com/freifunk-gluon/gluon/commit/7268e49a301fcd643a49b329bd60…
[10] https://github.com/freifunk-gluon/gluon/commit/7c2636d28264df20b448b0160b69…
[11] https://firmware.ffnw.de/20170822/
