Firmware 1.9: Details, Highlights

Firmware
1

Orginaler Blog-Post: https://freifunk-kreisgt.de/firmware-1-9-details-highlights/

Firmware 1.9 ist eine Interimsfirmware zum Sprung auf 2.0 und die erste Firmware des ›Nach-4/32-Zeitalters‹.

Mit Firmware 1.4 haben wir die Firmwarestände der übernommenen Freifunk-Netze Lüneburg und Bielefeld sowie Uelzen mit allen anderen Meshes auf einen Stand gebracht. Und wir werden diese Firmware auch im Bereich des Freifunk Lippe e. V. ausrollen, denn nur so kommen lippische 1.5er Knoten (auf Basis von Gluon v2021.1) ins neue, gemeinsame »Backend«. Insofern haben die Images ab 1.4.0~166 auch wieder eine (Migrations-) Konfiguration für Minden — Minden war ja von FFBI nach FFLP gewechselt …

Und da mehrere hundert Knoten keine Updates mehr bekommen, setzen die Images ab 1.4.0~166 auf diesen Systemen den Autoupdater-Zweig auf »deadend« (weil sie anderswo nicht mehr berücksichtig werden) und hängen an den Namen des Knotens ein »-EOL« an — als äußerliches Zeichen, daß hier wirklich Hand­lungs­be­darf besteht.

Analoges geschieht auch in Firmware 1.9 bzw. 2.0, auch hier werden beim Update die entsprechenden Änderungen vorgenommen. Das werden wir entsprechend fortführen, denn wegen des 8-64-Problems bleibt die Situation ›kompliziert‹, denn für 2.0/Gluon v.2023.2 – und damit für 1.9 die »deadend«-Regelung – gilt:

Removed hardware support

  • ath79-generic
    • TP-Link
      • Archer C60 (v1)
      • RE355
      • RE450 (v1)

Bislang wissen wir von keinen weiteren »Leichen«, die auf 1.9 hängen bleiben würden, und besagte Geräte werden wir mit dem Upgrade auf 1.9 in den »deadend«-Autoupdate-Zweig schieben …

2

Der Grund das die rausgeflogen sind ist IIRC das die Partitionierung des Flash für OpenWrt/Gluon Zwecke suboptimal ist und es effektiv leider nicht 8 oder 7 MB an verfügbarem Flash sind sondern weniger.
Es ist teils möglich durch Kombination von Partitionen dies zu umgehehen. Für manche Geräte ist das schon passiert. Das benötigt aber jemanden der sich das anschaut und testet. Und dann ist die zusätzliche Schwierigkeit das dies so passieren sollte das keine manuellen Eingriffe erfordert und definitiv keinen anderen bootloader braucht und auch ohne Probleme wieder zur Stock Firmware reverted werden kann wenn dies der Nutzer wünscht.

Wann es wirklich für 8/64 vorbei ist mag ich nicht beurteilen. Dafür bin ich da zu wenig drin. Aber ein wenig denke ich schon noch. Ich würde sie persönlich nicht kaufen und auch nicht empfehlen (wobei ich das AFAIR auch noch nie habe). Aber wie du schon sagst, die Situation bleibt am unteren Ende kompliziert.

1 „Gefällt mir“
3

Moin.

In der Version 1.9.0~2 für den »Ubiquiti UniFi AC Mesh Pro« gibt es einen Bug :beetle:, der mich ohne Probleme auf die Leiter brachte/bringt:
Der WAN-Port ist dort eth0.2 und nicht eth0.1. Mesh per WLAN war aus.
Somit war kein Mesh per WAN und auch kein Zugriff mehr auf die Geräte möglich.

Das Upgrade auf 2.0.0~4 brachte dies wieder in Ordnung. :smiling_face_with_three_hearts:

Zwischenablage_08-01-2025_03
Zwischenablage_08-01-2025_031841×743 41.8 KB

Zwischenablage_08-01-2025_04
Zwischenablage_08-01-2025_041835×743 42.2 KB

1 „Gefällt mir“
4

Moin,

einen habe ich noch …

auf dem Knoten 17209-Sietow-Hafen-38f0 war PoE-Weiterleitung aktiviert, um den dahinterliegenden Knoten zu versorgen.

# PoE passthrough ... add to /etc/rc.local
GPIO=20 # TP-LINK CPE210/510
echo $GPIO > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio$GPIO/direction
echo 1 > /sys/class/gpio/gpio$GPIO/value

Leider ist die rc.local beim Upgrade auf die 1.9.0~12 (leer) überschrieben worden.

Bei diesen TP-Link CPE210 ist br-wan und eth0 zum Glück nicht vertauscht worden.

1 „Gefällt mir“
5

AC Mesh Pro? Hmm. Das ist weird, weil:

1.9.02.0.0
elseif platform.match('ath79', 'generic', { 'ubnt,unifiac-mesh-pro', 'ubnt,unifiac-pro', }) then lan_ifname, wan_ifname = 'eth0.2', 'eth0.1' elseif platform.match('ath79', 'generic', { 'ubnt,unifiac-mesh-pro', 'ubnt,unifiac-pro', }) then lan_ifname, wan_ifname = 'eth0.2', 'eth0.1'

Sprich, da ist konfigmäßig zwischen 1.9 und 2.0 kein Unterschied?

Leider habe ich keine im Zugriff, um das genauer untersuchen zu können :frowning:

Auch das ist sonderbar; aber von rc.local wußte ich zuvor nicht mal :wink: Und »leer überschrieben«? Was sagt cat /rom/etc/rc.local?

BTW, hattest Du irgendwelche Probleme mit Euren ER-X — und wieso sind die alle schon auf 2.0? :wink:

6

Also ich finde auf die Schnelle nix, was explizit /etc/rc.local nullen würde im Code von Gluon v2023.1.2.

Hast Du eine spare CPE210 v1 zur Hand, die Du mit 1.4 installieren könntest, »echo >/etc/rc.local "logger foo"« machen und dann auf 1.9 upgraden könntest mit sysupgrade -v, siehe hier? Die Frage ist, wird da /erc/rc.local gelistet? Aber wenn nicht, mü0te /rom/etc/rc.local ›durchscheinen‹, sprich leer dürfte die Datei niemals sein?

7

Moin Kai.

Sorry. Hier habe ich mich etwas undeutlich ausgedrückt.
»Leer« bedeutete, meine Einträge sind nicht mehr in der Datei gewesen. Vermutlich ist die /etc/rc.local mit Default überschrieben worden.

Ich habe noch eine CPE210, wo ›PoE passthrough‹ keine Auswirkungen hat.

Einträge bei Version 1.4.0~169 … und sysupgrade:

  OS: 19.07-SNAPSHOT, r11430+27-ecbbb3    FW: 1.4.0~169
  HW: TP-Link CPE210 v1.1
root@17153-Juergenstorf-GH-RF:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

# PoE passthrough ... add to /etc/rc.local
GPIO=20 # TP-LINK CPE210/510
echo $GPIO > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio$GPIO/direction
echo 1 > /sys/class/gpio/gpio$GPIO/value

exit 0
root@17153-Juergenstorf-GH-RF:~#
root@17153-Juergenstorf-GH-RF:~# autoupdater -f -b rawhide
Retrieving manifest from http://firmware.ipv6.4830.org/rawhide/sysupgrade/rawhide.manifest ...
Stopping cron...
Stopping urngd...
Stopping micrond...
Stopping sysntpd...
Stopping gluon-radvd...
Stopping uhttpd...
Stopping sse-multiplexd...
Stopping gluon-respondd...
vm.drop_caches = 3
Downloading image:  7621 / 7621 KiB
Stopping network...

und jetzt nach dem Upgrade:

  OS: 22.03-SNAPSHOT, r20278+17-a08553    FW: 1.9.0~13
  HW: TP-Link CPE210 v1
root@17153-Juergenstorf-GH-RF:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

# PoE passthrough ... add to /etc/rc.local
GPIO=20 # TP-LINK CPE210/510
echo $GPIO > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio$GPIO/direction
echo 1 > /sys/class/gpio/gpio$GPIO/value

exit 0
root@17153-Juergenstorf-GH-RF:~#

:thinking: Seltsam! Mit der 1.9.0~13 war dies jetzt nicht reproduzierbar. :thinking:

8

Moin Kai. Danke für die Antworten.

Ich hatte gestern eins der drei Geräte (Volksbad) duch Downgrade gebrickt und wieder auf UBNT-Firmware gebracht. Nach dem Einspielen der Freifunk-Firmware 1.4.0~162 wurde »br-wan« und nicht »eth0.1/eth0.2« angezeigt. Das hat mich stutzig gemacht und habe bei den anderen beiden Geräten die Einstellungen mit »sysupgrade -n gluon-4830…bin« gelöscht. Nach der Erstkonfiguration der somit unkonfigurierten Geräten wurden nun auch dort »br-wan« angezeigt.
Das Upgrade des gebrickten Gerätes auf 1.9.0~13 und 2.0.0~4 brachten ebenfalls keine Änderungen an dieser Stelle.
Somit nehme ich an, dass die »felhlerhafte Anzeige/Konfig« auf eine Firmware (tng?) davor zurückgeht.

9

Könntest Du das bitte mit ~12 nochmals testen? ~13 basiert auf Branch v2023.1.x, davor war’s Tag v2023.1.2 — allerdings sehe ich in den 4 zus. Patches nichts mit Bezug zu /etc/rc.local …

10

hab gerade einen er-x sfp in feldberg auf 2.0 gehebelt. der hat alle upgrades ohne murren mitgemacht. (xx > 1.9 > 2.0)

11

Danke für die Info; per sysupgrade oder autoupdater -b?

12

autoupdater

1 „Gefällt mir“
13

Bei mir sind 1.9 und 2.0 auch nur über autoupdater auf den erx’n installiert worden.

1 „Gefällt mir“
14

Firmware 1.9 ist nun als stable im ganzen Netz ausgerollt. Ich würde das nun rund eine Woche ›sacken‹ lassen und in der Nacht auf nächsten Samstag die Migration auf 2.0 hinterher schieben.