Eigentlich hab ich mich damit auf die Checkliste bezogen, wie sie letztes Jahr mal angefangen wurde ^^
Für das alte target ar71xx wurde es damals natürlich sicher nie so genau überprüft ^^
ein Vergleich mit Gluon 2021 wäre eine Idee. Was ich weiß: Die rssi LED des dap-x1860 funktioniert aktuell ebenfalls nicht. (aber das Gerät hat zwei WiFi Radios)
OT: Wenn man statt wlan1 mesh1 setzt, leuchten jene Balken, wenn ein anderes Gerät mesht. Und mittlerweile gibt’s in OpenWrt auch 'nen Patch, daß die Power-LED grün leuchtet im Betrieb. Dies bitte ggf. in neuem Thread weiterdiskutieren.
Die RSSI-LED am weitesten rechts (also die für den höchsten Pegel blinkt im config-Modus etwa im Seundentakt. Sonst sind die RSSI-LEDs alle aus.
Vermutlich habe ich deren Funktion nur falsch erwartet.
Also die Rocket kann mesh - da sie aber nur 5GHz spricht muss man ihr sagen, dass sie sich Indoor befindet - zumindest wenn der andere Mesh-Partner eine Fritzbox 4040 in Indoor-Konfiguration ist.
Wenn dann die Mesh-TQ gut ist, klappt es auch mit den RSSI-LEDs. Mit anderen Worten: das funktioniert. Ich hatte erwartet, dass die LED die Verbindung zum Client anzeigen und mich schon ein wenig zur Sinnhaftigkeit gefragt…
achso
ja das ist dann unerwartet, bei Richtfunkantennen, die standardmäßig als Outdoor fungieren.
Bei Steckdosenwlanadaptern und anderen Geräten, die sonst rssi led’s verwenden, macht es aber Sinn, dort die Signalstärke der Meshverbindung(en) zu visualisieren.
Kann man mal überlegen, ob man dort von Gluon mal. Was ändern möchte. Man könnte für Mobilfunkrouter oder Outdoorantennen die LEDs anderweitig nutzen.
Derzeit wird standardmäßig immer das Mesh visualisiert. (und bei dual band offenbar nur eins)
Kurze Zusammenfassung, was uns noch fehlt:
Weiß nicht, was ich erwartet habe … Die Rockets werden ja nicht nur für Richtfunk verwendet sondern je nach Antenne auch für Abdeckung von Arealen.
root@platzhalter-murxmaster-rocket-m5:~# lua -e 'print(require("platform_info").get_image_name())'
ubiquiti-rocket-m-xm
Passt also. Der sysupgrade-Test folgt …
Das hab ich jetzt gemacht, nach einem Reboot war die SSID tatsächlich „UNFUG“. Ich habe dann wieder in den Konfigurationsmodus gewechselt und das gleiche Firmware-Image per Web-Interface hochgeladen mit der Option aktiviert die Konfiguration zu vergessen (oder habe ich deaktiviert die Konfiguration zu behalten? Egal!).
Nach dem Neustart waren im Konfigurationsinterface alle Felder zurückgesetzt (auch den VPN-Key musste ich neu eintragen lassen), danach war die Rocket wieder mit der regulären SSID freifunk.hannover.net online.
Der Teil scheint soweit geklappt zu haben - also weiter:
root@platzhalter-murxmaster-rocket-m5:~# sysupgrade -i /tmp/gluon-ffh-exp-20220711-ubiquiti-rocket-m-xm-sysupgrade.bin
Keep config files over reflash (Y/n):
Edit config file list (y/N):
Thu Jun 29 21:58:59 CEST 2023 upgrade: Saving config files...
Thu Jun 29 21:58:59 CEST 2023 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed
Hat dann offenbar die LEDs so bewegt, als wenn geflasht wird, ist neu gestartet und funktionierte. Test bestanden würde ich meinen.
root@platzhalter-murxmaster-rocket-m5:~# autoupdater
Retrieving manifest from http://firmware.ffh.zone/experimental/sysupgrade/experimental.manifest ...
autoupdater: warning: no matching firmware found (model ubiquiti-rocket-m-xm)
autoupdater: error: no usable mirror found
Okay, das geht aus offensichtlichen Gründen nicht.
Mir scheint, die Rocket M5 XM wird mit der Firmware gut unterstützt und scheint die Checkliste zu erfüllen, vielen Dank an insbesondere @Aiyion.Prime für die gute Arbeit sowie an explizit alle(!) anderen, die mich hier im Thread unterstützt haben.
Wenn ich noch sinnvollerweise Dinge testen kann: Sagt mir Bescheid.
Das dass Rücksetzen mit „configuration vergessen“ passiert: keine Frage.
Der Test war: Wird die Config übernommen und laufen die Initscripte?
Dafür z.B. FF-SSID verbiegen, dann das Update per sysupgrade von der Kommandozeile einspielen, ganz normal.
Und dann schauen ob der Router name und Hostkey herhalten blieben, die SSID aber zurückgesetzt ist.
root@platzhalter-murxmaster-rocket-m5:~# uci set wireless.client_radio0.ssid=UNFUG; uci commit
root@platzhalter-murxmaster-rocket-m5:~# sysupgrade /tmp/gluon-ffh-exp-20220711-ubiquiti-rocket-m-xm-sysupgrade.bin
Thu Jun 29 22:32:16 CEST 2023 upgrade: Saving config files...
Thu Jun 29 22:32:17 CEST 2023 upgrade: Commencing upgrade. Closing all shell sessions.
Danach kommt der Node mit der SSID hannover.freifunk.net wieder hoch, der VPN-Key und die anderen Einstellungen (Router name) sind erhalten geblieben.
Sieht also ganz gut aus.
Top, der Thread ist damit abgeschlossen und die Rocket kann neu hinzugefügt werden und es gibt bald für existierende Rockets da draußen Updates auf Gluon 22 
Danke
vielen Dank @Murxmaster, dass du dich da durchgewühlt hast, bedeutet mir eine Menge
Und vielen Dank an alle Beteiligten, die auf Ihre Art auch nur helfen wollten.
Dass der Thread technisch gesehen seit der erfolgreichen Suche eines Besitzers derailt ist, kann ich persönlich gut verschmerzen, wenn man sich überlegt, was sein einziger Zweck war.
So freue ich mich, Murxmasters letzten Post als Lösung markieren zu können und lasse euch wissen, wenn der entsprechendde PR gemergt wurde.
Die 2,4 GHz-Version ist von der Software ähnlich genug dass sie nicht getestet werden muss?
Kurze Frage noch: wie wäre denn das Vorgehen bzgl. WNDRMAC v2 (vgl. Gluon 2022.1 — Gluon 2022.1 documentation)? AFAICS ist die Hardware ja nur aus formalen Gründen (keine Checklisten-Protagonisten) aus Gluon v2022 rausgeflogen; um den lokalen Counterpatch loszuwerden, wie wäre das Vorgehen für die offizielle Wiederaufnahme?
Du baust dir in Anlehnug an die bestehenden Migrations Pull-Requests bei Gluon
ar71xx - ath79 migration progress · Issue #2413 · freifunk-gluon/gluon · GitHub einen Pull-Request für dein Gerät, baust eine Firmware gegen deinen gepatchten Master und gehst dann die Checkliste durch, wie es Murxmaster und all die anderen taten.
Aber ich glaube, daraus kann man langsam wirklich besser einen neuen Thread machen.
An alle anderen:
Danke nochmal, @rotanid hat heute morgen gemergt, damit haben wir jetzt über 100 migrierte ar71xx Geräte und Varianten 
@moderatoren Ich denke hier kann geschlossen werden.
edit zu früh gefreut.
Leider nicht. Die Rocket ist jetzt wohl unter ath79-tiny und der merge wurde abgelehnt.
Wenn mir jemand (@Aiyion.Prime ?) ein ath79-tiny Image bauen kann teste ich gerne erneut
FTR: da wir augenscheinlich die Majority der WNDRMAC2-Knoten betreiben, schenken wir uns den steinigen PR-Weg und enablen das einfach in unserer Gluon-based FW.
Kurzes Update:
Wir wechseln die Rocket gerade zurück in ath79-generic.
Die ist in tiny gelandet, weil sie als 32MB RAM Gerät verkannt wurde. (Sie hat 64MB und läuft damit noch rund im Gegensatz zu den meisten anderen airMAX Geräten mit XM-Board)
Ist die Wahrscheinlichkeit auf Erkenntnisgewinn erhöht, wenn ich die Hardware zum CCCamp23 einstecke?
Ich bin nicht auf dem Camp, aber die Wahrscheinlichkeit steigt auf jeden Fall
