Erste Testmigrationen von Testknoten mit Winterberger 0.10er Firmware waren erfolgreich, haben aber auch ein Problem gezeigt.
Während das schon geschilderte Verfahren per Eintrag in der /etc/hosts bei einem Winterberger Knoten mit Uplink wie geplant funktionierte – auch ohne gültige Signaturen von den Winterberger Admins wurde die 4830.org-Firmware heruntergeladen und installiert –, sträubte sich ein meshender Winterberg-Knoten, ebenfalls das Update zu holen.
tl;dr: Statt 2a06:e881:1709:1111:0:57ff:fefd:bc94 muß 2001:bf7:1311:f000::2 für den Migrationsfirmwareserver verwendet werden. Erklärung folgt …
Hintergünde
Es stellte sich heraus, daß die Winterberger Firmware ihr öffentliches IPv6-Präfix fest einkodiert hat — im Netz des 4830.org e. V. ›vergibt‹ das Gateway die Adressen¹. Mesht nun ein Knoten mit Winterberger Firmware mit einem mit der 4830.org-Migrationsfirmware, erhält der Knoten mit alter, Winterberger, Firmware plötzlich zwei öffentliche IPv6-Adressen: eine vom Gateway² des 4830.org-Netzes sowie eine durch die Winterberger Firmwareeinstellungen. Zwar gibt es nur eine Standard-Route, aber aufgrund von Besonderheiten des Internet Protokolls in der Version 6 (IPv6) wählt der Knoten eventuell die falsche IPv6-Absendeadresse:
BusyBox v1.30.1 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 19.07-SNAPSHOT, r10951+8-1713707673
-----------------------------------------------------
root@Migrationstest-a0f3c1848d76:~# uptime
14:13:59 up 8:04, load average: 0.00, 0.04, 0.03
root@Migrationstest-a0f3c1848d76:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2019.2-4, MainIF/MAC: primary0/72:f8:0f:14:4e:53 (bat0/a0:f3:c1:84:8d:76 BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
* 02:ca:ff:ee:27:75 (232) 22:c5:e3:28:9b:a1 [ mesh0]: 1024.0/1024.0 MBit
02:ca:ff:ee:27:82 (204) 22:c5:e3:28:9b:a1 [ mesh0]: 1024.0/1024.0 MBit
root@Migrationstest-a0f3c1848d76:~# echo -e "2a06:e881:1709:1111:0:57ff:fefd:bc94\tfirmware1.freifunk-winterberg.net firmware2.freifunk-winterberg.net" >>/etc/hosts
Während der meshende Knoten IPv6-Adressen und Standard-Gateway vom 4830.org-Netz bekommt und auch andere Server per IPv6 erreichen kann …
root@Migrationstest-a0f3c1848d76:~# traceroute -6 one.one.one.one traceroute to one.one.one.one (2606:4700:4700::1111), 30 hops max, 64 byte packets 1 2001:bf7:1310:27::52 (2001:bf7:1310:27::52) 47.251 ms 52.562 ms 51.778 ms 2 2a06:e881:1705:ffff:0:82:93:0 (2a06:e881:1705:ffff:0:82:93:0) 60.784 ms 60.977 ms 64.214 ms 3 2a06:e881:1705:a2a1::2 (2a06:e881:1705:a2a1::2) 61.756 ms 66.767 ms 63.295 ms 4 retn.a36.community-ix.de (2001:7f8:a5::9002:1) 62.593 ms 58.553 ms 52.940 ms 5 cloudflare.bcix.de (2001:7f8:19:1::3417:1) 54.345 ms 58.967 ms 56.248 ms 6 2400:cb00:67:1024::a29e:f571 (2400:cb00:67:1024::a29e:f571) 63.098 ms 2400:cb00:67:1024::a29e:f566 (2400:cb00:67:1024::a29e:f566) 84.033 ms 54.745 ms
… klappt letzteres gerade mit dem 4830.org-Updateserver nicht (die neue Adresse haben wir oben mit dem echo-Befehl lokal gesetzt):
root@Migrationstest-a0f3c1848d76:~# traceroute -6 firmware1.freifunk-winterberg.net traceroute to firmware1.freifunk-winterberg.net (2a06:e881:1709:1111:0:57ff:fefd:bc94), 30 hops max, 64 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * *^C
Der Grund war nicht ganz trivial, aber mit Bordmitteln zu ergründen:
root@Migrationstest-a0f3c1848d76:~# ip -6 route get 2a06:e881:1709:1111:0:57ff:fefd:bc94 2a06:e881:1709:1111:0:57ff:fefd:bc94 from :: via fe80::f0be:efff:fe00:2782 dev br-client src 2a03:2260:300d:8000:a2f3:c1ff:fe84:8d76 metric 512
Als Absendeadresse zu 2606:4700:4700::1111 wird die funktionierende Adresse aus dem Bereich des 4830.org, 2001:bf7:1310:27:a2f3:c1ff:fe84:8d76, genommen; als Absendeadresse zu 2a06:e881:1709:1111:0:57ff:fefd:bc94 die 2a03:2260:300d:8000:a2f3:c1ff:fe84:8d76, welche Freifunk Winterbergs alte Infrastruktur verwendet, zu der wir hier aber gar keine Verbindung mehr haben.
¿Warum?
IPv6, das aktuelle Internetprotokoll, versucht eigenständig, die ›beste‹ ausgehende IPv6-Adresse für das jeweilige Ziel auszuwählen, wenn mehrere vorhanden sind und keine vorgegeben wurde. Daher wird für 2a06:e881:… die 2a03:2260:… verwendet, für 2606:… die 2001:… — wieso, weshalb, warum kann der geneigte Leser (d/m/w) im RFC 6724 nachlesen.
Lösung
Wir hatten erst vor, auf den Gateways die 2a03er Adressen in 2a06er umzuschreiben (NAT66), haben dann aber den einfacheren Weg gewählt und dem Updateserver temporär eine IPv6-Adresse aus 2001:… verpaßt. Damit klappte es auch mit einem meshenden Knoten ohne Uplink mit Winterberger Firmware, der hinter einem mit Uplink und 4830.org-Migrationsfirmware hing. Flugs den Eintrag in /etc/hosts angepaßt und schon klappt’s:
root@Migrationstest-a0f3c1848d76:~# vi /etc/hosts root@Migrationstest-a0f3c1848d76:~# traceroute -6 firmware1.freifunk-winterberg.net traceroute to firmware1.freifunk-winterberg.net (2001:bf7:1311:f000::2), 30 hops max, 64 byte packets 1 2001:bf7:1310:27::52 (2001:bf7:1310:27::52) 52.027 ms 66.738 ms 46.776 ms 2 2a06:e881:1705:ffff:0:82:98:0 (2a06:e881:1705:ffff:0:82:98:0) 74.968 ms 55.424 ms 68.800 ms 3 firmware1.freifunk-winterberg.net (2001:bf7:1311:f000::2) 77.087 ms 78.072 ms 94.427 ms
Beim nächsten Aufruf des Autoupaters wurde dann auch die Firmware getauscht:
Wed Dec 31 16:52:03 2025 daemon.info td-client: Reinitializing tunnel context. Wed Dec 31 16:52:04 2025 daemon.err haveged[698]: haveged: Stopping due to signal 15 Wed Dec 31 16:52:04 2025 daemon.err haveged[698]: Wed Dec 31 16:52:05 2025 kern.info kernel: [ 5641.073916] sysctl (12614): drop_caches: 3 Wed Dec 31 16:52:06 2025 daemon.err td-client: Hostname resolution timed out. Wed Dec 31 16:52:06 2025 daemon.err td-client: Hostname resolution timed out. Wed Dec 31 16:52:07 2025 daemon.info td-client: Reinitializing tunnel context. Wed Dec 31 16:52:09 2025 daemon.info td-client: Reinitializing tunnel context. Wed Dec 31 16:52:10 2025 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds Wed Dec 31 16:52:16 2025 daemon.info td-client: Performing broker selection... Wed Dec 31 16:52:18 2025 daemon.notice hostapd: client0: interface state ENABLED->DISABLED Wed Dec 31 16:52:18 2025 daemon.notice hostapd: client0: AP-DISABLED Wed Dec 31 16:52:18 2025 daemon.notice hostapd: client0: CTRL-EVENT-TERMINATING Wed Dec 31 16:52:18 2025 daemon.notice hostapd: nl80211: deinit ifname=client0 disabled_11b_rates=0 Wed Dec 31 16:52:18 2025 kern.info kernel: [ 5653.890001] device client0 left promiscuous mode Wed Dec 31 16:52:18 2025 kern.info kernel: [ 5653.895168] br-client: port 3(client0) entered disabled state Wed Dec 31 16:52:18 2025 daemon.notice netifd: Network device 'client0' link is down
Fazit
Wie schon beschrieben, können alle Knoten mit Winterberger Firmware 0.10.x – das sind rund 570 der 650 Knoten, die in der aktuellen Winterberger Infrastruktur online sind – von den Knotenbetreibenden ohne Zutun der Winterberger Admins ins Netz des 4830.org e. V. migriert werden. Hierzu ist einzig der Eintrag
2001:bf7:1311:f000::2 firmware1.freifunk-winterberg.net firmware2.freifunk-winterberg.net
auf jedem zu migrierenden Knoten in die Datei /etc/hosts einzutragen. Ja, für die Betreibenden sehr aufwendig, aber immerhin gut zu wissen, sollte die Winterberger Infrastruktur völlig zusammenbrechen, sind noch nicht alle Knoten verloren …
Die Winterberger Admins können alternativ im DNS dafür sorgen, daß firmware1.freifunk-winterberg.net und/oder firmware2.freifunk-winterberg.net auf die IPv6-Adresse 2001:bf7:1311:f000::2 zeigt (Achtung, andere IPv6-Adresse als zuvor genannt!). Dann würden *alle* Winterberger Knoten mit Firmware 0.10.x auf die 1.4.0~194 des 4830.org e. V. und damit in dessen Winterberg-Auffang-Meshes migriert werden — mit bekanntlich ein paar Ausnahmen³. Um auch die restlichen Knoten mit einer Firmware neuer als 0.10.x zu migrieren, müßten die Admins das Manifest mit ihren Winterberger Schlüsseln signieren und uns z. B. per Mail zusenden. Sobald eine mit Winterberger Signaturen versehene Manifest-Datei auf dem Firmwareserver hinterlegt wurde, würden auch die Knoten mit neuerer Firmware nachziehen.
Knoten, die weiterhin mit Firmwareupgrades versorgt werden, werden sich dann nach wenigen Stunden auf die auf Gluon v2023.1 basierende Firmware 1.9.0 aktualiseren – von Gluon v2020.1 auf v2023.1 in unter einem Tag, möglich wäre es ;-)
That’s all, folks! Guten Rutsch und ein recht neues 2026!
¹ ja, richtig, rein technisch beziehen die Endgeräte im Freifunknetz ihre IPv6-Adressen SLAAC, dafür muß aber ein Präfix bekanntgegeben werden, was in diesem Falle das Gateway tut und das in einem Nebensatz zu erklären machte den Satz nicht einfacher ;-)
² Gateway und Supernode sind funktionell hier austauschbare Begriffe
³ Wie schon geschrieben, 3 Knoten <0.9 blieben auf der Strecke (würden durch das Update vermutlich bricked), ebenso sind wohl 4 ERX nach dem Upgrade per serieller Schnittstelle wiederzubeleben