Firmwarebäckerei: 1.9.0~78

Firmware
1

Orginaler Blog-Post: Firmwarebäckerei: 1.9.0~78 - 4830.org

Nach längerer Pause tut sich nochmal was bei den Versionen unserer „stable“-Firmware.

Ab 1.9.0~78 sind primär folgende Änderung an Bord:

  • Wechsel auf community-maintained packages für autoupdater-wifi-fallback und ssid-changer
  • Erweiterung PUMP, jetzt ist auch Uplink per WLAN möglich (aber, wie beim PUMP, nur mit dediziertem Funkmodul („Radio“))
  • Patches für DAP-X1860: Grüne System-LED hinzugefügt, nach dem Boot wechselt die System-LED auf grün (und die Signalstärkeanzeige folgt mesh1 statt dem nicht existenten wlan1)
  • Bugfix bei Konfiguration von gluon-radv-filterd

Leider sind auch ein paar Geräte negativ aufgefallen, deren Flash-Speicher für die erweiterten Funktionen nicht ausreichend ist:

  • arcadyan-vgv7510kw22
  • d-link-dap-1330-a1
  • d-link-dap-1365-a1
  • d-link-dir-505
  • d-link-dir825b1
  • librerouter-v1
  • netgear-r6020
  • netgear-wndr3700
  • netgear-wnr2200-8m
  • nexx-wt3020-8m
  • ravpower-rp-wd009
  • tp-link-archer-c20i
  • tp-link-archer-c20-v1
  • tp-link-archer-c2-v1
  • tp-link-archer-c50-v1
  • tp-link-archer-c60-v1
  • tp-link-archer-c6-v2-eu-ru-jp
  • tp-link-archer-d50-v1
  • tp-link-cpe210-v1
  • tp-link-cpe210-v2
  • tp-link-cpe210-v3
  • tp-link-cpe220-v3
  • tp-link-cpe510-v1
  • tp-link-cpe510-v2
  • tp-link-cpe510-v3
  • tp-link-td-w8970
  • tp-link-td-w8980
  • tp-link-tl-wdr3500-v1
  • tp-link-tl-wdr3600-v1
  • tp-link-tl-wdr4300-v1
  • tp-link-tl-wr1043nd-v2
  • tp-link-tl-wr1043nd-v3
  • tp-link-tl-wr2543n-nd
  • tp-link-tl-wr810n-v1
  • tp-link-wbs210-v1
  • tp-link-wbs210-v2
  • tp-link-wbs510-v1
  • ubiquiti-nanostation-loco-m-xw
  • ubiquiti-nanostation-m-xw
  • ubiquiti-unifi-ap

Diese Systeme haben jetzt schon die Grenze ihres Flash-Speichers erreicht, derzeit sinnieren wir, ob wir sie offiziell „anzählen“ und entsprechend auf der Karte als nicht mehr empfehlenswert markieren.

Firmware für den Ravpower RP WD009 wird wegen Buildproblemen in 2.1.0 (v2025.1) z. Zt. nicht mehr mitgebaut. Das Teil ist von 2019 und nicht mehr neu kaufbar, eher kein wirklicher Verlust, zumindest gibt’s bislang davon keine Geräte bei uns.

Was ist zu tun?

Bitte testet die folgenden Aspekte mit 1.9.0~78 (aktuell in testing und experimental) und 1.9.0~79 (aktuell in rawhide) oder später:

  • WLAN-basiertes Update (autoupdater-wifi-fallback-Paket): Knoten auf 1.9.0~78 bringen im testing-Branch, dann z. B. ins Mesh 66 verschieben/installieren, auf rawhide-Branch ändern und danach WAN kappen — der Knoten müßte nun isoliert sein vom Mesh. Wenn ein irgendeine »Freifunk«-SSID ausstrahlender AP erreichbar ist, sollte binnen weniger Stunden sich der Knoten auf 1.9.0~79 aktualisiert haben. Das wäre dann gelegentlich zu prüfen, z. B. per Verbindung mit der FF-OFFLINE-SSID und Zugriff per nextnode-IP (::1 der v6-ULA-Adresse des Netzes).
  • PUMP-Funktionalität 1: einen Knoten als PUMP-AP, mindestens einen weiteren als PUMP-STA, gerne auch eine Strecke PUMP-AP (5 GHz), PUMP-STA (5 GHz)/ PUMP-AP (2 GHz), PUMP-STA (2 GHz)/Mesh-on-LAN, Mesh-on-LAN/FF AP und Mesh auf 2 und 5 GHz. Funktioniert das zuverlässig? Durchsatz OK?
  • PUMP-Funktionalität 2: Knoten per WLAN an privates WLAN hängen (nicht(!) Freifunk — Tunneldigger-L2TP-Tunnel zu den Gateways durch einen L2TP-Tunnel saugt; sollte funktionieren, aber ist auf mehreren Ebenen schlecht) und gucken, wie gut das tut und wie stabil das ist verglichen mit Verbindung per WAN.
  • Generell Stabilität, Neuinstallation von OEM-Firmware (ja, ich weiß, schwierig ;-)), Klickorgien im Config-Mode gerade zwischen „WLAN“- und „PUMP“-Menüs und was Euch noch so einfällt.
  • Interoperabiliät 1.4.0, 1.9.0, 2.0.0, 2.1.0 in Meshes
  • Autoupdater-Updates: dafür ist 1.9.0~78 in testing/experimental und 1.9.0~79 in rawhide

Latent soll 1.9.0~78+x die letzte 1.9.0er werden und kurzfristig nach stable gehen.

Warum hampelt Ihr 2026 noch immer mit Gluon v2023.1.x rum?

Das ist so ein »Longtail«-Thema; der neue Drecks-Editor von WordPress läßt keine Inline-Bilder mehr zu, daher bleibt nur die extene Referenz, macht sie Euch parallel in einem neuen Fenster auf …

Von Gluon v202x.y kann man nur direkt auf bestimme andere Gluon-Versionen updaten.

Das betrifft insofern v2021.1.x – unsere 1.4.0 in deadend –, von wo man nur nach v2022.1.x oder v2023.1.x updaten kann. Solange wir also Netze von „ziemlich alt“ auf 2021.1.x bringen, um danach via v2023.1.x auf v2025.1.x zu migrieren, wäre es fatal, wenn wir stable auf mehr als v2023.1.x hätten — die Knoten würden evtl. zwar upgraden, aber die Konfiguration dabei verlieren. Und insofern behindert die Übernahme anderer Communities auch unseren Weg nach vorne.

Die aktuelle Planung sieht vor, daß wir bis Ende August 2026 alle zu übernehmen Netze übernommen haben werden und dann 2.1.0, Gluon v2025.1.x-based, zur stable wird.

2

Achtung, das funktioniert erst ab 1.9.0~85 (baut gerade für alle Targets, ~180 Minuten) wirklich — selbst eine KI schafft die Gluon-Integration nicht aus dem Stand :wink:

3

… 1.9.0~88, hopefully. WLAN-als-Uplink war doch eher eine Zangengeburt, da br-wan komplett ersetzt werden mußte (Unterschiede auf Layer-3 vs. Layer-2, yadda-yadda). Es ist schon faszinierend, mit einer KI zu coden:

Ja, beide Punkte folgen aus der Trennung von pumpwan aus br-wan: Wir haben zwar Layer-3-WAN, aber Gluons DNS-/Firewall-Pfade hängen noch an den klassischen WAN-Namen bzw. der WAN-Firewall-Zone. Ich mache fix19 so, dass pump_wan/pump_wan6 in die wan-Firewall-Zone aufgenommen werden und der WiFi-Uplink-DNS über Gluons WAN-DNS-Pfad nutzbar wird.

Das LLM hat also wohl »verstanden«, wie Gluon per se funktioniert und der »Hinweis«, $Dinge im Config-Mode zu unterlassen, wurde quittiert mit dem Kommentar, dies sei ein guter Punkt sei, da überflüssig … von sich aus daran »zu denken« allerdings hat nicht geklappt :slight_smile:

1.9.0~88 scheint jedenfalls das alles nun soweit zu beachten, daß erstmals eine Meshverbindung via Tunneldigger durch einen WLAN-AP (hier eine Fritzbox 7530 per LAN1-WAN am Glasfaser-Anschluß-LAN) zustande gekommen ist.

root@33332-Test-d460:~# batctl gwl
[B.A.T.M.A.N. adv 2022.0-openwrt-9, MainIF/MAC: primary0/2a:5e:02:aa:99:bb (bat0/a8:63:7d:2c:d4:60 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
* 02:ca:ff:ee:01:47 (255) 02:ca:ff:ee:01:47 [  mesh-vpn]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:46 (225) 02:ca:ff:ee:01:47 [  mesh-vpn]: 1024.0/1024.0 MBit
root@33332-Test-d460:~# batctl tr 02:ca:ff:ee:01:46
traceroute to 02:ca:ff:ee:01:46 (02:ca:ff:ee:01:46), 50 hops max, 20 byte packets
 1: 02:ca:ff:ee:01:47  40.027 ms  41.314 ms  43.273 ms
 2: 02:ca:ff:ee:01:46  62.719 ms  55.358 ms  60.308 ms
root@33332-Test-d460:~# ip -4 route show
default via 192.168.188.1 dev pumpwan proto static src 192.168.188.35 
10.234.128.0/20 dev local-node proto kernel scope link src 10.234.128.1 
192.168.188.0/24 dev pumpwan proto kernel scope link src 192.168.188.35

1.9.0~88 ist nach testing gewandert, es baut sich auf identischer Codebasis die 1.9.0~89, die dann in rawahide für Upgrade-Tests zur Verfügung steht: zu testen ist, ob bzw. inwiefern das Package ffac-autoupdater-wifi-fallback mit dem PUMP-Zeug kollidiert.

4

FTR: 1.9.0~90 hat nun auch einen angepaßten autoupdater-wifi-fallback-Mechanismus an Bord, der PUMP-Links nicht mehr langfristig stören sollte …