Nanostation M2 loco XW bricked /kaputtgeflashed

Technik Hardware
1

Hallo,

habe eine Nanostation M2 loco XW. Diese lief mal mit Freifunk, habe dann ein „normales“ aktuelle Openwrt draufgeflasht. Das lief auch, wollte dann aber zurück zur Stock Firmware von Ubiquity. Also habe ich von der Openwrt GUI aus AirOS 5.6.1 unsigned geflashed… das war keine gute Idee.

Jetzt ist der Router nicht mehr per LAN-Schnittstelle erreichbar. Imemerhin scheint es eine Art Bootvorgang zu geben und ich komme auch per Resetknopf gedrückt halten und dann erst das PoE-Kabel einstecken in einen besonderes Modus (TFTP? LEDS blinken bunt im Wechsel), allerdings kann ich mit einem TFTP-Programm (ich habe Pumpkin versucht) keine Firmware auf den Router brinen.

Habe auch schon nach dieser Anleitung hier:
https://openwrt.org/toh/ubiquiti/nanostationm2

einen USB-TTL Adapter (CH340G) besorgt und an die Pins auf der Platine angeschlossen.
Ich bekomme im Terminalprogramm (Putty oder tera-term) jedoch nur kryptischen Output
UK▒닁1.L▒j▒e58 I*▒▒10 2▒5 K▒▒Ҫ▒:2J
▒!▒5: 4 S▒H▒

und kann selbst keine Eingaben machen.

Ich nutze einen Windows 10-Laptop. Habe sonst mit Terminal, TFTP, seriellen Protokollen etc. nichts zu tun sondern handele nach Anleitungen…

Hat jemand noch eine Idee, was ich noch versuchen kann?

Danke schon mal…

2

Ich an Deiner Stelle würde beim Ansatz mit tftp bleiben. Du schreibst nicht, was da genau schief ging, allerdings liest es sich so, als würde das bei der Station grundsätzlich noch funktionieren.

Bei Deinem Ansatz mit der Console hat vermutlich die Geschwindigkeit nicht richtig funktioniert, die solltest Du bei den Terminalprogrammen einstellen können.
Aus Deiner Anleitung: Open up a terminal program, such as tera-term, and configure it to the following settings:
Bits per second: 115200
Data Bits : 8
Stop Bits : 1
Parity : None
Flow control : None

3

Falls Du „teilweise lesbaren Output“ bekommst, dann hilft Dir evtl. dieses 3 Jahre alte Posting:

4

Danke euch.

Über TFTP bekomme ich leider die Firmware nicht übertragen. Manchmal startet die Übertragung, aber nie vollständig. Nach den Anleitungen wird das auch nicht funktionieren ohne den urescue-Befehl im Terminal?

Die Geschwindigkeit hatte ich im Treiber des USB-Adapters sowie auch in Tera-Term und Putty auf 115200 8N1 eingestellt (mit solchen Themen hatte ich seit meinem Umstieg vom analogen 56k-Modem auf DSL ca. im Jahr 2000 nichts mehr zu tun…).

Den anderen Adapter CP2102 kann ich auch aus Forschungsinteresse mal probieren. Wenn das nicht geht, kommt das Ding wohl in die Tonne.

5

Vielleicht hilft dir ja meine Leidensgeschichte weiter.
Wie du lesen kannst bin ich auch mit praktisch jedem Flashvorgang gescheitert, bis ich den einen seeligmachenden Weg gefunden habe:

Und bevor du den Ziegel wegwirfst schenke ihn lieber mir, vielleicht will er nur ein neues Zuhause haben :smiley:

1 „Gefällt mir“
6

Also, der Tip mit dem CP2102 Adapter hat mich schon weitergebracht! Das Terminalprogramm (tera-term, putty) zeigt nämlich jetzt folgendes an:
"U-Boot 1.1.4-s958 (Jun 10 2015 - 10:56:20)

DRAM: 64 MB
Flash: 8 MB (0xc2, 0x20, 0x17)
Net: AR8032 Detected
eth0, eth1
Board: Ubiquiti Networks AR9342 board (e867-131848.1122.0030)
Radio: 0777:e867
Reset: Normal
Hit any key to stop autoboot: 0

Booting image at 9f050000 …

Bad Magic Number
Boot failed: resetting…
"
und damit hängt das Gerät in einer Boot-Schleife. Ich drücke zwar fleißig Tasten („Hit any key to stop autoboot:“), aber der Bootvorgang lässt sich dadurch nicht unterbrechen. Habe irgendwie den Eindruck, dass die Eingaben nicht im Gerät ankommen. 115200 8N1 etc. ist eingestellt. der PC ist auf feste IP 192.168.1.123 eingestellt.

Mir fällt noch auf, dass am USB to TTL-Adapter die kleine LED de „TXD“-Pins dauerleuchtet.

Wert hat dazu noch eine Idee?

7

Jetzt hat es doch geklappt, habe in den Adaptereinstellungen im Windows Gerätemanager die 115200 eingestellt (default ist 9600) und nochmal die Verkabelung geprüft. Dann konnte ich den Bootvorgang stoppen und den urescue Befehl eingeben!

Jetzt versuche ich gerade die Airos Firmware 5.6.15 mit Pumpkin per TFTP zu übertragen. Leider bricht der Vorgang nach einiger Zeit ab(retry count exceeded…), help please…

8

Der TFTP-Transfer war sehr langsam und hat immer bei ca. 130kb abgebrochen. Gerade mal auf die Idee gekommen, dass es am Kabel liegen könnte, habe nämlich ein 10m LAN-Kabel benutzt. Flugs getauscht gegen ein Patchkabel mit 20cm Länge und nochmal versucht. Und ZACK waren die 7MB Firmware in wenigen Sekunden übertragen!

9

Also, es hat tatsächlich geklappt, jetzt ist wieder die Stock-Firmware drauf und funktioniert auch wieder! Ich hatte die Nanostation fast schon abgeschrieben.

Letztlich hat der urescue-Befehl die Nanostation auch in den TFTP-Modus (sichtbar an den blinkenden LEDs) gebracht, ,diesen Modus konnte man auch über die Resettaste auch ohne diesen Befehl erreichen. Seinerzeit hatte bei mir dann aber auch die Übertragung der Firmware per TFTP nicht funktioniert und ist abgebrochen, was im Nachhinein wohl am zu langen LAN-Kabel lag. Vielleicht hätte es also sogar ohne den Adapter und den urescue-Befehl funktioniert. Mein Forscherdrang geht aber nicht so weit, das noch wieder auszuprobieren…

Vielleicht nützt mein „Live-Bericht“ hier einigen, die auf ähnliche Probleme stoßen.

Vielen Dank für Eure Mithilfe!

Für Feinschmecker hier noch der Terminal „Dialog“

ar7240> urescue -f -e
Using environment IP
Boot loader overwrite mode
Starting TFTP server…
Using eth0 (192.168.1.20), address: 0x81000000
Waiting for connection: /
Receiving file from 192.168.1.123:65162
Received 7373322 bytes
Firmware Version: XW.ar934x.v5.6.15.30572.170328.1052
Setting U-Boot environment variables
Un-Protected 1 sectors
Erasing Flash… done
Erased 1 sectors
Writing to Flash… write addr: 9f040000
done
Protected 1 sectors
Copying partition ‚u-boot‘ to flash memory:

First 0x0 last 0x3 sector size 0x10000
… done
write addr: 9f000000
Copying partition ‚kernel‘ to flash memory:

First 0x5 last 0x14 sector size 0x10000
… done
write addr: 9f050000
Copying partition ‚rootfs‘ to flash memory:

First 0x15 last 0x7a sector size 0x10000
… done
write addr: 9f150000

Firmware update complete.

Resetting…

U-Boot 1.1.4-s958 (Jun 10 2015 - 10:56:20)

DRAM: 64 MB
Flash: 8 MB (0xc2, 0x20, 0x17)
Net: AR8032 Detected
eth0, eth1
Board: Ubiquiti Networks AR9342 board (e867-131848.1122.0030)
Radio: 0777:e867
Reset: Normal
Hit any key to stop autoboot: 0

Booting image at 9f050000 …

Image Name: MIPS Ubiquiti Linux-2.6.32.68
Created: 2017-03-28 7:53:41 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 956233 Bytes = 933.8 kB
Load Address: 80002000
Entry Point: 80002000
Verifying Checksum at 0x9f050040 …OK
Uncompressing Kernel Image … OK

Starting kernel …

Booting Atheros AR934x

1 „Gefällt mir“
10

Auch wenn Du es jetzt irgendwie hinbekommen hast, falls andere später über diesen thread stolpern sollten in ähnlicher Lage:

  1. Anderer ethernet-Adapter, möglichst „dummen“ 100MBit-Switch dazwischenhängen.
    Aus irgendeinem Grund sind meist der tcp-stack oder die (routerseitige) Switch-Initiatlisierung seitens des Bootloades eher so „works for factory/service“, also nicht für den Produktionsbetrieb.

  2. notfalls kann man die Firmware auch per kermit, xmodem, ymodem, hexdump (oder was auch immer der bootloader beherrscht, googeln…) übertragen. Also nicht per Lan, sondern Datei-Upload über den seriellen Konsolenlink aus dem Minicom&Co selbst.
    Das kann durchaus ein paar Minuten dauern. Aber fühlt Euch dann wie die DFÜ-Datenreisenden der späten 1980er, wo man froh war, wenn die „Ausbeute“ einer Nacht am Terminal eine randvolle 720kB-Diskette war…