@DH5AT bezieht sich auf den Text von @0liver. Der spricht von 5.6.
Ich rede von 5.5.
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.
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.
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.
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
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.
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).
Auch ich habe gestern eine Nanostation gebrickt, weil ich das hier gelesen habe (Gluon 2016.1.1 — Gluon 2016.1.5 documentation):
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?
Kann ich nicht. Hier direkter Weg von AirOS5.6 auf 2016.1.5 erfolgreich bei XW.
Bei einer Picostation vor zwei Wochen hat’s auch sofort geklappt.
Hm, also USB-auf Serial kaufen…
Hab’ noch genug dieser Adapter hier liegen, kann dir gern einen zukommen lassen
Vielen Dank, schon vor dem Mittag bestellt: 7,99 bei A***. Soll morgen da sein.
Stolzer Preis
Wäre bei Amazon auch nicht billiger gewesen, wenn man es per Prime/Morning-Express haben wil.
Sind vermutlich die gleichen Händler, die parallel auf mehreren Platformen aktiv sind.
Obwohl, da war’s nur der „billige“ CHG340 gewesen, aber immerhin kein notorisch gefälchter Prolific230x.
Was ich merkwürdig finde, ist dass bei Euch der Rescue-Mode nicht funktioniert. Denn in dem Szenario kenne ich es nicht, dass der nicht mehr will.
Ist ja von dort, ich wollte bloß den Namen nicht nennen
Rescue-Mode: Habe ich da was übersehen? Wie geht das?
Ach so, das „Alxnder Hrngk Leiden“. Ich glaubte, das hätte sich 15 Jahre nach dem Untergang des Fidonet erledigt.
Rescue Mode:
oder wenn das nicht geht, dann:
Hallo adorfer,
mit tftp habe ich es schon probiert, mir war nur nicht klar, dass das als Rescue Mode bezeichnet wird.
Ich kann die aktuelle FW von ubnt flashen, dann bleibt die Nanostation in einer boot-Schleife hängen. Andere Images (auch die 5.5.x) werden mir „Firmware check failed“ abgelehnt.
Ich habe es mit der Anleitung von ubnt hinbekommen, zurück auf V5.5 zu gehen und dann Gluon neu zu flashen. Diesmal hat’s geklappt.