Ich werde nicht wiederholen, was ich anderswo schon geschrieben oder verlinkt habe.
Thema dieses Threads ist „Rocket XM gesucht“ (für Test von Gluon 22/23).
Manchmal ist es besser den Mund zu halten oder von seinem hohen Ross runterzusteigen. So ein Verhalten vergrault uns Murxmaster. Nur weil du keine Lust hast, die Threads erneut durchzusehen, heißt das nicht, dass kein anderer bereit ist, das zu tun oder ihm Fragen zu beantworten.
Er macht das gerade zum ersten Mal, ist sich nicht sicher und bekommt nur zurück: ja musst du selber herausfinden, RTFM…
Das ist einfach nicht zielführend.
Wie gesagt, wieder ein UBNT-Thread, der letztlich das Thema „wie flashen“ bekommt.
Die ganzen Threads kommen ja nicht daher, dass es besonders einfach wäre UBNT zu flashen im Gegenteil. Und viele Infos da draußen sind dann wieder teilweise veraltet (ohne, dass man sieht wie) oder man findet die genannten Images nicht mehr zum Download.
BTT:
Kannst dich ja gerne zurückmelden @Murxmaster, ich führe dich da gerne durch
Es gibt genügend Threads zum Thema „Fragen zum Flashen von UBNT-Geräten“. Die sind alle nicht geschlossen und können neue Fragen bekommen.
Alternativ lassen sich auch einfach neue „Gerät mit Openwrt xy-flashen“-Threads aufmachen.
Das fortgesetzte Derailen von Threads ist das was stört.
Und die nächsten mit ähnlichem Problem finden es wieder nicht, weil natürlich niemand in „Besitzer gesucht“ schaut. Ist nicht sinnvoll auffindbar.
Danke, das war wirklich hilfreich. Die für mich wichtige Information war: "Das Flashen der Rocket M5 (XM) wird nach dem gleichen Schema durchgeführt wie bei der Ubiquiti NanoStation M2 / Loco M2.
Vielen Dank.
EDIT:
@Aiyion.Prime: Ich habe das Image nun auf meiner Rocket installiert und die SSID hannover.freifunk.net ist sichtbar, ich bekomme aber noch keine IP zugewiesen. Ich warte einfach noch ein wenig, sonst muss ich wohl noch einmal in den Konfigurationsmodus und nachsehen, ob ich das VPN über Ethernet wirklich aktiviert habe …
EDIT: In Hannover muss man den VPN-Key verschicken. Erledigt,
Das Gerät hat ja nur ein 5GHz Radio soweit ich das sehe. Dementsprechend musst du immerhin schon mal nur ein Radio testen (das wäre aber sonst auch kein Problem).
Also einfach ein Endgerät nehmen, verbinden und schauen ob die Verbindung tut.
Dafür brauchst du ein zweites Gerät welches die Frequenzen unterstützt die du testen willst. Das stellst du dann daneben und schaust ob die beiden miteinander meshen. Das geht zum Beispiel auf der Statusseite. Die TQ sollte natürlich (wenn die wirklich nebeneinader stehen) bei etwa 100% liegen.
Radio LEDs Should map to their respective radio - die leuchten nicht.
Should show activity rssi - die leuchten nicht im Normalbetrieb
Switch port LEDs: Should map to their respective port (or switch, if only one led present)
Switch port LEDs: Should show link state and activity:
Outdoor devices only: Added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua - wurde zumindest auf der Konfugurationsseite als Outdorgerät belegt.
Fehlend: „Must have working sysupgrade“: wie teste ich das am besten? (Ja, ich kann mich am CLI der Rocket anmelden)
einen Versionsstring setzen, der einen geringeren ascii-sort hat als die aktuelle FW des community-autoupdate-servers. Und dann ca. 60 min warten, alternativ „autoupdate -f“
Beispiel:
echo 20160101>/lib/gluon/release
Das setzt natürlich voraus dass es für diese Hardware in der Community überhaupt eine Firmware auf dem Update Server gibt. Alternativ natürlich einfach die gleiche Software als sysupgrade noch mal drauf flashen, die schon drauf ist.
Und bei dem Vorgang am besten per serieller Console zuschauen, ob das zumindest logisch ausschaut.
Wenn Du kein anderes FW-Image (als das bestehende) hast, dann geht die Kontrolle nur teilweise, und auch nur sinnvoll, wenn Du eine serielle Konsole hast, damit Du zumindest „zugucken“ kannst.
Also: Sysupgrade-Image als $IMAGE nach /tmp laden
dann „sysupgrade /tmp/$IMAGE“ und zuschauen, ob das Ding mit den gleichen Settings wiederkommt.
Wenn Du schauen willst, ob die systupgrade-init-Scripte gelaufen sind, vielleicht die SSID von Freifunk vergurken und schauen ob nach dem Update wieder sinnvolle werte stehen.
Also vor dem sysupgrade noch
uci set wireless.client_radio0.ssid=UNFUG; uci commit
Puh. Ich würde die Hürde nicht so hoch hängen — sysupgrade auf die gleiche Version sollte doch reichen, autoupdater funktioniert oder nicht unabhängig von der HW. Was willst Du denn als Qualitätsmanagement per serieller Console bewerten? IMHO ist ein fehlerfreies gluon-reconfigure (also $? == 0) ausreichend?
Bei „sysupgrade auf die gleiche Version“ ist via ssh schlecht zu unterscheiden, ob das Upgrade/flashen durchgeführt wurde oder ob es wegen irgendeines Problems (z.B. flash konnte nicht unlocked weden) abgebrochen und das Ding mit der „alten“ Firmware neu startet.
Du lenkst vom Thema (»serielle benötigt ja/nein«) ab. Dein Vorschlag bezog sich auf »[w]enn Du schauen willst, ob die systupgrade-init-Scripte gelaufen sind«, Deine Begründung für einen seriellen Zugang im nächsten Post lautete »[es sei] via ssh schlecht zu unterscheiden, ob das Upgrade/flashen durchgeführt wurde«. Nach Deiner eigenen Argumentation ist ein serieller Zugang nicht notwendig, wenn man den vollzogenen Flash-Vorgang anders verifizieren kann.
Dann erläutere ich es anders:
Wenn eine serielle Console vorhanden ist, dann lässt sich der Vorgang auch ohne Config-Änderungen beobachten auf Grundlage „abwesenheit von Fehlermeldungen“, also z.B. "abbruch weil irgendwelche Signaturen oder Checksummen nicht stimmen.
Wenn keine Serielle Console vorhanden ist, dann besteht die Möglichkeit, Config-Dinge zu verbiegen, die vom Sysupgrade durch die (bei Erfolg) anschließend ausgeführten Upgrade-Scripte wieder auf Site.conf-Values zurückgebogen werden.
Dazu zählt z.B. (in Stock-Gluon) die Freifunk-SSID. Oder z.B. die FQDNs der Supernodes.
Dieser indirekte Test hilft natürlich nur für den Fall, dass die Firmware (der syupgrade-Teil der Firmware) nicht dermaßen broken ist, dass die Upgradescripte nicht doch aufgerufen werden, obwohl das flashen vorher gefailt ist, z.B. weil nicht erkannt wurde, dass das writeprotect des SPI-flashes gar nicht entfernt wurde, der (mtd-flasher, oder was immer es auch war) aber keinen Errorlevel zurückgegeben hat.
Will sagen: Der indirekte Test ist daher nur „2nd-best“ und strenggenommen nicht exhaustive.
Besser wäre also ein Sysupgrade z.B. auf eine Firmware einer anderen Community, wenn keine upgrade-Test-Firmware (also kein n+1-build) vorhanden ist.
Oder auch auf Plain-Openwrt zurück. Dann ist sichergestellt, dass der Flashvorgang als solches im aktuellen FW-Image funktioniert.
rssi led’s ist komisch. Die haben vermutlich schonmal funktioniert. Da wird @Aiyion.Prime sicher drauf zurück kommen, sobald er Zeit hat.
Den outdoor devices Eintrag macht er, sobald er das Gerät hinzufügt. Die Instruktion ist für den PR gedacht, da muss im Quellcode eine Datei um einen Eintrag erweitert werden.
Was noch fehlt:
Blinkt die power led sekündlich, wenn die rocket im config modus ist?
Den Gluon profile name könntest du noch per ssh überprüfen/auslesen
sysupgrade mit config behalten (oben beschrieben, ein sysupgrade aufs gleiche image) und einmal mit config vergessen
Must keep/forget configuration (sysupgrade [-n], firstboot)
Für mit „config vergessen“ kannst du ein
„sysupgrade -n“ nach openwrt ausführen wie von Adorfer vorgeschlagen. Dann ist der erfolgreiche config reset auch abgehakt.
Das geht auch aus dem config mode. einfach den Haken raus nehmen bei „Konfiguration behalten“
da würde ich micht nicht unbedingt darauf verlassen, das Gerät ist recht alt, damals wurde nicht so genau geprüft wie heute bei Aufnahme von Hardware.
Am Besten ließe sich das checken, indem man eine alte Firmware flasht.
und am Ende gilt: solange das Gerät mit der ath79 firmware nicht schlechteren support hat als mit ar71xx, passt es, „besser“ zu erwarten ist doch Quark
(Weiß nicht, wie ich das valide testen kann)
- die leuchten nicht im Normalbetrieb