Ubiquiti (Loco/Nanostation M2 (xw/xm)) auf Original Firmware zurückflashen


#29

Was würdest Du damit anfangen?

Ich würde durchaus gerne ein bis zwei der Stationen tauschen gegen (etwas) ältere funktionstüchtige, da ich hier noch ein kleines Projekt fertig machen möchte. Sechs Stück sind ja noch unberührt. Nur die eine habe ich halbtot gemacht.

Ich traue mich jetzt auch nicht, die ältere Version (5.5.11) per Webinterface auf eine weitere Station zu kopieren. Wenn das auch schief geht, habe ich nachher nur noch Leichen hier herumliegen. Das kann ich mir im Moment gar nicht leisten.

Aber vermutlich würde sie sich auch wehren mit einer Fehlermeldung…

Für andere Ubiquiti-Hardware habe ich irgendwo gelesen, dass es eine Transfer-Version gibt, die nur dazu gemacht wurde, dass man dann anschließend jede Firmware-Version aufspielen könne… Aber das finde ich nicht wieder. Hatte auch irgendwas mit Version 7.0.x und 7.1.x zu tun…

Ich habe mal dem Support eine kurze Mail geschrieben. Mal sehen, wann die dort ihren Neujahrsrausch ausgeschlafen haben und ob dann eine Antwort kommt. Ich kann mir nicht vorstellen, dass die das ignorieren, insbesondere da die Einsatzzahlen der Loco M2 gerade erst anfangen zu wachsen.

Grüße
Tom


#30

Ich hätte halt gern eine “defintiv betroffene”, in Stock-Zustand.
Mag sein, dass ich nicht so ganz hinterherkomme, was das Problem ist, aber die Forenthreads (auch “außerhalb”) und möglichen Lösungen sind so zahlreich, zumal viele nicht so recht beschreiben, mit welchen Geräten sie genau welche Ausgangssituation hatten.
Daher würde ich gern versuchen das nachvollziehen.
Ziel wäre “ein dokumentierter sauberer Weg”.
Und eine möglichst universelle Recovery-Methode.


#31

Die erste Antwort ist schon da:

## Please do not write below this line ##

Your request (247215) has been updated. You can add a comment by replying to this email.

----------------------------------------------

Phillip S, Dec 31, 11:52

Hi Thomas,

Thanks for getting in touch with us!

I regret to inform you that we would not be able to support any devices that are loaded with custom firmware.

Thanks!


Phillip S
Ubiquiti Networks

Wieviel Prozent Ubiquiti-Equipment wird bei uns in den deutschen Freifunk-Commuities zusammen ungefähr eingesetzt? Wie könnte ich das in Erfahrung bringen?

Jedenfalls wird es nun niemand mehr einsetzen, wenn wir das Rätsel nicht gelöst bekommen.

Grüße
Tom


#32

Das kann ich gerne nochmal zusammenkramen.
Die meisten Ausgaben habe ich mir in einer Datei abgelegt.
Ich habe mehrere Wege versucht.

Eine von den jungfräulichen Stationen könnte ich Dir per Päckchen schicken, wenn Du mir dafür eine andere (etwas ältere) sendest, die ich einsetzen kann. Ich lasse die Leute ungerne lange warten, auch wenn es ehrenamtlich ist…

Grüße
Tom


#33

Hallo Wissende,

was müsste ich denn tun, um das komplette System von einer original belassenen Station auf die halbtote zu übertragen?

Mir fällt kein anderer Weg ein, wie man die angebrickte sonst retten könnte. Es scheint ja wohl der Loader für die Firmware geschreddert worden zu sein?

“Philip S” von Ubiquity hat sich nochmal gemeldet, ob wir noch mehr Input für ihn haben. Es könnte sich also eventuell doch ein Dialog ergeben, der uns generell weiterhelfen könnte.

Denn eines scheint mir nach reichlichem Internetstudium sicher zu sein:

Das Probllem betrifft ab sofort bis auf Weiteres alle Ubiquiti-Router-Hardware, nicht nur die Nanostations!

Wo kann ich nachlesen, wie das benutzte Arbeitsprinzip mit dem AR7240 und der Gluon-Build-Firmware funktioniert?

Grüße
Tom


#34

Ein Beitrag wurde in ein neues Thema verschoben: Ubiquiti mit Stockfirmware XW.v5.6.X erst downgraden (+recovery)

Es geht ja dabei vorrangig um “gluon auf die XW-Boards”, nicht um das hier angesprochene “stockfirmware zürick auf XM nach dem Gluon schon lief” (dieser Thread).


#35

kann das sein, dass ich die Stock-Firmware erst trimmen muss, bevor ich die Gluon-FW mittels tftp damit überschreibe?

Grüße
Tom


#36

nein das geht auch so wenn du den downgrade auf 5.5.x gemacht hast


#37

Hallo zusammen,

nach einer fehlgeschlagenen Firmwareänderung zu einem gluon-Image wollte ich frohen Mutes zunächst zur Originalfirmware zurück.

Also, das Reset-Procedere begonnen (TFTP-Verbindung funktioniert), das aktuelle Image (XM.v5.6.2.27929.150716.1201.bin) heruntergeladen und die böse Überraschung erlebt: die Firmware wird aufgespielt, die NanoStation bootet später aber nicht richtig und meldet nichts im Netzwerk, lediglich Power und LAN leuchten, die 4. und 5. LED blinken ca. alle 8 Sekunden kurz orange (4.) / grün (5.) auf.

Leider werden alle anderen Images, die ich ausprobiert habe, in etwa so quittiert:

echo -e “binary\nrexmt 1\ntimeout 60\ntrace\nput firmware.bin flash_update\n” | tftp 192.168.1.20
tftp> Packet tracing on.
tftp> sent WRQ <file=flash_update, mode=octet>

received ERROR <code=2, msg=Firmware check failed>
Error code 2: Firmware check failed
Sent 3538944 bytes in 5.0 seconds

Vielleicht hat jemand von Euch Erfahrung damit und eine Idee?

Danke und einen schönen Sonntag!
Oliver


#38

Hallo,

ich habe im April leider das gleiche Problem.

Hat jemand eine Lösung dazu?

Grüße
Axel


#39

Schon mal probiert mit TFTP auf die alte Stock zurückzukehren?


#40

Vermute ich: “Ja”. Denn darauf bezieht sich Axel doch.

(Das Thema habe ich mal zusammen gelegt, weil es alles “das gleiche” ist.)


#41

@DH5AT bezieht sich auf den Text von @0liver. Der spricht von 5.6.

Ich rede von 5.5.


#42

ich konnte die XM.v5.6.2.27929.150716.1201.bin per tftp auf das Gerät übertragen. Nach dem Upload gibt es ein “Lauflicht” bei den Signalstärke LED.
Mehr passiert aber nicht und ich kann das Gerät auch nicht auf der 192.168.1.20 erreichen. :frowning:


#43

Hatte gleiches Problem mit meiner NanoStation Loco M2. Das Problem konnte ich nur mit einen USB TTL-Konverter-Modul mit eingebautem in CP2102 lösen. Habe mit Putty die Verbindung zur Nano aufgebaut und folgendes ausgeführt:

mtdparts default
saveenv
boot

Die Firmware (bei mir) XM.v5.6.3.28591.151130.1749.bin per tftp flashen. Hab die Verbindung zur Nano über Webbrowser 192.168.1.20 hergestellt und dort unter SYSTEM einen Reset durchgeführt. Danach war das Problem gelöst.


#44

Sollte der uboot bootloader beschädigt worden sein (was passiert, wenn FF auf ein airOS 5.6x geflasht wird), kann per serieller Schnittstelle die Nanostation mit dem command “urescue -f- e” in einen Modus versetzt werden, der per TFTP airOS flashing auch den uboot bootloader neu schreibt. Danach nochmal mit “urescue” ohne -f -e airOS flashen. Danach sollte die Nanostation wieder funktionieren.


#45

Hallo Uwe,
Hallo Clemens,

danke für die Tipps. Ich bin ein Stück weiter gekommen, aber noch nicht am Ziel.

Nachdem ich mich mit der seriellen Konsole mit dem Gerät verbunden habe und die Kommandos

mtdparts default
saveenv
boot

eingegeben habe, bootet das Device erwartungsgemäß.
Ein Reset im SYSTEM Menü ging, ABER dann hing das Gerät wieder in der Bootschleife. Auch ein Update auf die Firmware 5.6.4 brachte nicht.
Das Gerät bleibt in der Bootschleife, es sei denn, man holt es einmal mit der oben aufgeführten Befehelssequenz raus.

Grüße
Axel


#46

noch ein Update:
es läuft nun. puhhh.

Nicht wirklich nachzuvollziehen wieso, aber egal. Es waren x TFTP uploads mit rescue/ rescue -f -e/ mtdparts default/ saveenv/…

Danke an Euch.


#47

Sehr schön, DH5AT, dass es geklappt hat. Ich hatte auch die Beobachtung, dass es mitunter mehrmals augenscheinlich die gleiche Prozedur braucht, bis so eine Nanostation wieder geht. (z.B. mehrmaliges flashen mit gleichen Parametern).


#48

Auch ich habe gestern eine Nanostation gebrickt, weil ich das hier gelesen habe (http://gluon.readthedocs.io/en/v2016.1.5/releases/v2016.1.1.html):

Downgrading to AirOS 5.5.x before flashing Gluon on Airmax M XM/XW devices (NanoStation, Bullet, …) is not necessary anymore.

Wir haben Beta-FW basierend auf Gluon v2016.1.5. Mit der hat’s aber nicht geklappt. Symptome wie hier beschrieben.
Kann das jemand bestätigen, dass das Problem weiterhin besteht?