Heads up: Firmware 2.1.0 incoming

wusel · December 27, 2025, 3:40pm

Orginaler Blog-Post: Heads up: Firmware 2.1.0 incoming – Freifunk Kreis GT

Die Spatzen pfeiffen es von den Dächern, das Gluon-Team wird in Kürze eine neue Basis-Firmware – Gluon v2025.1 nach aktuellem Stand – veröffentlichen. Höchste Zeit, bei ›uns‹ aufzuräumen

Unsere nächste Firmware wird die Versionsnummer 2.1.0 tragen und auf besagter Gluon-Version – vermutlich also v2025.1 genannt – basieren. Für die technisch Interessierten folgen unten noch ein paar Aussagen zu dem, worauf wir uns wohl freuen dürfen. Zuvor aber allgemeine Hinweise, denn manch ein Knoten braucht noch etwas Liebe ….

Firmwarestände und Aufgaben für Knotenbetreibende

Mehrfach thematisiert, daher hier nur kurz: Firmwareupdates sind nur möglich von unserer Version 1.4.x auf 1.9.0 und erst von dort auf 2.0.0 — andere Vorgehensweisen¹ lehnen die Geräte in seltenen Fällen ab, führen leider aber latent eher zu einem ›Brick‹, also einem schicken neuen Türstopper in WLAN-Router-Form. Im besten Fall verliert der Knoten ›nur‹ seine Konfiguration und wartet im Config-Mode auf Angaben.
Das alles wollen wir vermeiden, daher müssen wir sicherstellen, daß wir in den Autoupdater-Kanälen (stable, experimental, …) nur Knoten, die von ihrem aktuellen Firmwarestand sicher auf die 2.0.0 sich aktualisieren können, diese Firmware auch anbieten. Heißt im Umkehrschluß: alle Knoten z. B. im stable-Zweig müssen auf 1.9.0 sein, bevor wir 2.0.0 dort per Autoupdater anbieten können.

Durch entsprechende Maßnahmen in den letzten Wochen sind wir »fast« am Ziel — das Gros der Knoten, die derzeit eine Verbindung ins Mesh haben, sind auf einer 1.9er, teils schon auf einer 2.0er, Version, das ist gut. Knoten, die nicht mehr über 1.4.0 hinaus aktualisert werden können, sind weitestgehend im Zweig deadend ›geparkt‹².

Knoten, die über eine längere Zeit ausgeschaltet waren und vorher kein mögliches Update auf 1.9.0 sich geholt haben, werden nach dem Wiedereinschalten dann vor einem Update auf 2.0.0 stehen — und ggf. ein ›Debrick‹ bzw. eine Neukonfiguration benötigen. Dies ist leider nicht vermeidbar, die Karawane zieht jetzt weiter. Bei entsprechenden Problemen wendet Euch bitte an die Ansprechpartner Eurer jeweiligen Community.

Reminder: Den Zustand Eurer Knoten könnt Ihr wie immer am einfachsten über die Karte ermitteln und verfolgen. Und wenn Ihr das automatische Updating der Firmware deaktiviert habt, ist genau jetzt der Zeitpunkt, manuell ein solches Update durchzuführen!

Leider wandern sowohl in Firmware 1.9.0 als auch in 2.0.0 weitere Geräte aus dem Supportstatus raus — bitte habt das auf dem Schirm, liebe Knotenbetreibende! Auch diese Geräte wandern in den Zweig deadend.

Sobald wir die Knoten wenigstens auf 1.9.0, besser noch 2.0.0, haben, stehen dem nächsten Update auf 2.1.0 nur noch unsere Anpassungen und Tests im Weg ;-)

Highlights Firmware 2.1.0 auf Basis »Gluon Next«³

Geräte mit mehreren Funkmodulen (›Radios‹) können nun von Gluon aus unterstützt werden — also einerseits Funkmodule für das 6-GHz-Band, andererseits auch die »Mesh«-Geräte mit 2 5-GHz-Modulen, die nicht beide alle 5-GHz-Frequenzen abdecken können.
Bei AVM FRITZ!Box 7520/7530 wird nun der LAN1-Port als WAN-Port verwendet — man gewinnt also 3 LAN-Ports für Clients und/oder Wired-Meshing. 7520/7530 werden so Offloader-tauglich.
Bei Geräten mit Mediatek-WiFi-Chipsätzen wurde die Stabilität und Interoperabilität wohl deutlich verbessert.
Offizielle Unterstützung viele aktueller Geräte (von denen wir einige mit TripleRadio schon länger in unserer FW unterstützten).
Verbesserungen in der Behandlung von Multicast-Paketen im Netz bedingen mehr denn je homogene Firmwarestände in den Meshes.

Die Vorarbeiten an 2.1.0 sind schon gestartet, wir peilen eine Veröffentlichung im 1. Quartal 2026 an — natürlich auch davon abhängend, wann ›v2025.1‹ tatsächlich veröffentlicht und wie sich diese Basis in anderen Communities schlagen wird.

_____
¹ ja, es ginge auch 1.4.0 nach 1.6.0 nach 1.9.0 nach 2.0.0, aber eben nicht direkt von 1.4.0 nach 2.0.0
² außer im Autoupdate-Zweig ›mns‹, die werden gesondert behandelt
³ soweit basierend auf den »commit«-Nachrichten ables-/vorhersagbar

wusel · January 4, 2026, 11:15pm

Gluon v2025.1 liegt als 2.0.1~6 im master-Zweig bereit für erste Tests; noch ohne Signaturen für den Autoupdater, das sollte erst einmal per sysupgrade kontrolliert ausprobiert werden … Volunteers? Wenn ein paar Tests gelaufen sind, wird das als 2.1.0 mit signierten Manifesten gebaut werden …

Njumaen · January 5, 2026, 1:49am

Ich teste gerne mit meiner Offloader-VM!

Apropos Test: Würde zu gern mal wireguard/vxlan als Ersatz für fastd testen….

Frohes Neues

Ralf.

Njumaen · January 5, 2026, 5:35am

bin drauf!

https://map03.4830.org/map09/#!v:m;n:bc2411b9c8c9

wusel · January 5, 2026, 7:07am

Moin!

Nice! Bitte insbesondere auf die Interface-Zuordnungen achten im Freifunk- und Config-Mode (sprich: läuft beides über WAN?), da sich da viel geändert hat.

Puh, schwierig, da wir schon seit >5 Jahren kein fastd mehr einsetzen Die Verbindung läuft über L2TPv3, wie auch beim später hinzugefügten Modus bei fastd. Wireguard + VXLAN sind zwei aufeinander gestapelte Tunneltechniken, Wireguard für die Layer-3-Verbindung Knoten <> Gateway, darin dann VXLAN für eine Layer-2-Verbindung, wie batman-adv sie benötigt.

Und durch den Layer-2-Tunnel schicken wir batman-adv-Pakete. Jeder Tunnel benötigt etwas Platz für seinen eigenen Protokolloverhead, sprich verringert die Paketgröße von 1500 (Ethernet) bzw. 1492 (Telekom-VDSL) bzw. noch kleiner (1450 oder so bei CGNAT mit IPv4 über IPv6) für das nächstinnere Protokoll. Und auch wenn’s alles kernelinterne Protokolle sind (L2TPv3, VXLAN, Wireguard als auch batman-adv), so muß dennoch jedes IP-Paket durch jedes Protokoll von der CPU durchgeschoben werden. Insofern dürften L2TP via tunneldigger oder fastd die effizientesten Methoden sein – 1 äußerer Tunnel –, Wireguard + VXLAN müßte etwas geringen Durchsatz bieten – 2 äußere Tunnel –, bei gleichen sonstigen Umgebungsparametern (identische Knoten-CPU, identisches Transportnetzwerk (1 GBit/sec-Link im Labor), Gateway-VM auf identischem Hypervisor und identische iperf3-Gegenstelle).

Den Vorteil, den Wireguard für Freifunk erbringt – einen komplett verschlüsselten Tunnel –, erkauft man sich mit der Notwendigkeit, einen L2-Tunnel – L2TP oder VXLAN oder GRE oder … – zusätzlich aufbauen zu müssen, in dem dann Batman funktioniert. Da ›hinter‹ dem Gateway gen Internet eh’ nichts mehr transportverschlüsselt wird, stellt sich weiter die Sinnfrage, warum wir den Datenverkehr zwischen Konten und Gateway (in D/EU) unbedingt verschlüsseln sollten?

Thomas · January 5, 2026, 8:53pm

Habe gerade auch einen meiner knoten ajtualisiert.
https://map03.4830.org/map/#!v:m;n:0896d7a1deb3

Hat bisher ohne Probleme funktioniert. Werde es mal die nävhsten Tage weiter testen.

wusel · January 9, 2026, 12:27am

FTR, 2.1.0~2 baut gerade in Hamburg, mühsam knabbern die Cross-Compiler sich durch den Code:

ffgt@basilisk:~/build$ tail -F /tmp/build-2.1.0~2.log
 1: mediatek-filogic     built with RC 0 at Fri 09 Jan 2026 00:54:51 CET, took 33 minutes
 2: ramips-mt7621        built with RC 0 at Fri 09 Jan 2026 01:05:38 CET, took 10 minutes
 3: ath79-generic        built with RC 0 at Fri 09 Jan 2026 01:18:29 CET, took 12 minutes
[…]

Gluon v2025.1 läßt sich leider nicht komplett unter Debian 13 bauen (zugrundeliegendes OpenWrt ist bei ramips-mt7621 inkompatibel zu swig 4.3.0, lange traurige Geschichte), sonst ließen sich auf Reste-Rampe-Rechnern von Hetzner deutlich kürzere Kompilierungszeiten realisieren:

ffgt@granny:~/build/gluon-4830-v2025.1/site-4830-v2025.1$ cat /tmp/build-2.0.1~7.log 
 1: mediatek-filogic     built with RC 0 at Tue Jan  6 04:20:24 AM CET 2026, took  7 minutes
 2: ramips-mt7621        built with RC 2 at Tue Jan  6 04:22:56 AM CET 2026, took  2 minutes
 3: ath79-generic        built with RC 0 at Tue Jan  6 04:27:42 AM CET 2026, took  4 minutes
[…]

Naja, nachher ist auch noch ein Tag

Thomas · January 10, 2026, 8:34pm

Meinst du ich könnte auch mal einen Offloader Updaten? Und schauen ob meine Config mit VLAN bestehen bleibt?

wusel · January 10, 2026, 10:42pm

Gerne! Wenn das VLAN ab v2022.1 aka unserer 1.6.0 über /etc/config/gluon – vgl. Forum und Docs (unten, ab »Furthermore«) – konfiguriert wurde, soll das upgradefest sein. Da wir keine 1.6er Knoten mehr haben, ist 1.9.0 die erste Version, wo so ein Setup updatefest konfiguriert werden kann und von wo es auch beim direkten Upgrade 1.9.0 ⇒ 2.1.0 keine Probleme geben sollte.

Reminder:
1.4.0 basiert auf Gluon v2021.1 — letzte FW für 4/32
1.6.0 basiert auf Gluon v2022.1 — zurückgezogen da übersprungen
1.9.0 basiert auf Gluon v2023.1 — letzte Firmware u. a. für Archer C60 v1
2.0.0 basiert auf Gluon v2023.2 — letzte Firmware u. a. für ERX, da kein Auto-/sysupgrade möglich auf nächste Version
2.1.0 basiert auf Gluon v2025.1 — aktuellste Gluon-Version (Release: Dezember 2025)

Njumaen · January 10, 2026, 11:01pm

VM jetzt auf Firmware 2.1.0~8

http://[2001:bf7:1318:ffff:be24:11ff:feb9:c8c9]/cgi-bin/status

Thomas · January 11, 2026, 11:52am

Hmm, ich habe es über

cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

uci show network | grep "\.vlan='15'" || {
  uci add network switch_vlan
  uci set network.@switch_vlan[-1].device="switch0"
  uci set network.@switch_vlan[-1].vlan="15"
  uci set network.@switch_vlan[-1].ports="1t 6t"

  uci set network.vid15="interface"
  uci set network.vid15.ifname="eth0.15"
  uci set network.vid15.proto="none"

  uci add_list network.client.ifname="eth0.15"
  uci commit network

  /etc/init.d/network restart
}

exit 0

gelöst. (Und dann je nach Modell immer etwas angepasst)

/etc/config/interfaces wird manchmal überschrieben, richtig?
/etc/config/gluon nicht?

wusel · January 11, 2026, 12:36pm

Genau:

Starting with release 2022.1, the wired network configuration is rebuilt from /etc/config/gluon upon each gluon-reconfigure. Therefore the network configuration is overwritten at least with every firmware upgrade.

Thomas · January 11, 2026, 1:07pm

Das Update ist mit einer Hürde durch gelaufen.

Ich musste den Knoten einmal zusätzlich nach dem Update neustarten, da mein Script unter /etc/rc.local scheinbar das Mesh VPN nicht aufbauen lassen hat.

wusel · January 11, 2026, 2:05pm

Danke für’s Update.

Okay, das sollte dann der neue Watchdog – nach 135 Minuten ohne Verbindung zum Mesh wird rebootet – notfalls auffangen. Ich würde dennoch dazu raten, die Konfiguration von /etc/rc.local nach /etc/config/gluon zu migrieren, weniger Individualität ist besser

Thomas · January 11, 2026, 3:50pm

Werde ich machen, muss ich aber auch erst durch testen. Habe für mich jetzt erst einmal einen Sleep Befehl nach dem Networkrestart gesetzt und lasse dann den Tunneldigger noch neustarten- Damit sollte auf den anderen Knoten nichts passieren.
Werde in der nächsten Woche auch noch einmal einen meiner Testknoten auf Werkseinstellungen setzen und neu einrichten.

Thomas · January 18, 2026, 12:27pm

Ich habe den 33378-TH-Test-1200 einmal per firstboot gelöscht und per Wizard eingerichtet. Hat alles ohne Probleme geklappt.

wusel · January 18, 2026, 11:28pm

Danke! Allerdings ist Dir, wie mir, dies hier doch durchgerutscht

Ja, von uns liest diese Seite niemand, aber für Neueinsteiger sollte sie doch korrekt sein.

Ab 2.0.0~13 ist das dann auch gefixt:

(»Südwestfalen-Lippe« umfaßt die Knoten ›links‹ des Kreises Gütersloh bis in etwa Gelsenkirchen und nach Süden grob bis zum Möhnesee (dessen Mesh ein eigenes Viereck bildet):

Nur, falls es jemanden interessiert )

Thomas · January 23, 2026, 4:36pm

Meine beiden Testknoten haben das Update auf die aktuelle TNG Firmware (2.1.0~12) nicht ohne Komplikationen überstanden.

Beide wahren Offline.

Sie strahlten beiden weder ein WLAN Signal aus, noch waren sie per LAN Kabel erreichbar. Einen Neustart hat der 1200 auch nicht auf Anhieb akzeptiert. Ich habe ihn eine Minute am Strom weg lassen müssen. (Warum auch immer).. Der 300e hat für den Neustart auch gefühlt sehr lange gebraucht, (ca 2 Minuten)

grafik

grafik
2.1.0~10 → 2.0.1~12

2.0.1~6 → 2.0.1~12

Betraf es nur meine beiden?

wusel · January 24, 2026, 1:53pm

Bei meinen Knoten sind mir noch keine ›Verluste‹ aufgefallen, aber das will nichts heißen …