Ubiquity AirOs5.6 / U-Boot-Änderung: Brick-Gefahr: Rocket M2/Nanostation /LocoM (erst downgraden auf AirOS5.5) für Gluon 2015.x


#21

@eriu
Hab endlich Zeit zum Basteln gehabt. Nach deiner verlinkten Anleitung klappte es leider nicht. 5.5.xx Firmware blieb leider im Booting hängen und 5.6.xx Firmware hatte einen Bootloop zur Folge. Habe mir einen USB -> TTL Wandler gekauft und damit im Terminal mit urescue -f und dann mit tftp die 5.5.xx Firmware + alster UBoot Version aufspielen können. Und von da die FF Firmware installiert bekommen. Hatte es im Ubnt Forum gelesen. Vielleicht könnt Ihr das mit in eurer Anleitung aufnehmen. Übrigens Klasse das Ihr eure Benutzer vor dem Problem mit den Ubiquiti AP warnt.


#22

Wir warnen auf unserer Website: https://md.freifunk.net/mitmachen/firmware/

Wichtig: Auf dem Gerät oder auf der Verpackung steht nicht welche Version der Hardware es ist. diese sieht man nur in der Weboberfläche der Orginalfirmware

ACHTUNG: Bei Ubiquiti mit der Firmware AirOS XM.v5.6.X / XW.v5.6.X (oder neuer) kommt es zu Komplikationen. Ein direktes Einspielen der Freifunk Firmware ist NICHT MÖGLICH.

Es ist notwendig bevor man die Freifunk Firmware oder OpenWRT aufspielt, zuerst ein Firmwaredowngrade auf die Version AirOS XM.v5.5.X oder XW.v5.5.X durchzuführen. Ohne diesen Firmwaredowngrade WIRD DAS GERÄT NICHT BOOTEN!

Wenn dein Gerät nicht mehr bootet, bitte folge folgender Anleitung im wiki: Debrick a Nanostation

Dafür sind folgende Schritte notwendig:

Einloggen in das Webinterface des UBNT Gerätes
(idR 192.168.1.20)
Download der Passenden Firmware AirOS XM.v5.5.X
Download AirOS XM.v5.5.11.28002.150723.1344.bin, changelog
for: AG-HP-2G16, AG-HP-5G23, AG-HP-5G27, AirGrid M2, AirGrid M5, AR, AR-HP, BM2HP, BM2-Ti, BM5HP, BM5-Ti, LiteStation M5, locoM2, locoM5, locoM9, M2, M3, M365, M5, M900, NB-2G18, NB-5G25, NBM3, NBM365, NBM9, NS2, NSM3, NSM365, NSM5, PBM10, PBM3, PBM5, Power AP N
Download AirOS XW.v5.5.10-u2.28005.150723.1358.bin,(backup link changelog
for: AG-HP-2G16, AG-HP-2G20, AG-HP-5G23, AG-HP-5G27, AirGrid M, AirGrid M2, AirGrid M5, locoM2, locoM5, locoM9, M2, M3, M365, M5, M900, NBE-M2-13, NBE-M5-16, NBE-M5-19, NSM2, NSM3, NSM365, NSM5, PBM3, PBM365, PBM5, RM2-Ti, RM5-Ti
Auswahl der AirOS XM.v5.5.X Firmware des Gerätes
Aktualisierung auf AirOS XM.v5.5.X (mit Neustart des Gerätes)
Überprüfung ob AirOS XM.v5.5. tatsächlich eingespielt wurde
wenn ja: jetzt kann das Einspielen der Freifunk-Firmware starten

Update: Ich hab für das Downgrade von UBNT Geräten eine Anleitung geschrieben: https://wiki.md.freifunk.net/Anleitungen/router-flashen-ubnt


#23

Hallo,

habe ich alles schon gemacht. Ich schreibe mir auch immer erst die Statusseite ab (Firmware, MAC, …), bevor ich loslege. Leider habe ich eure Warnung erst zu spät gesehen.

plug device in, release reset button as soon as LEDs blink

kann ergänzt werden:
…dauert sehr lange. Erst blinkt die grüne Ethernet-LED, dann kommt ein paar Sekunden nichts, dann blinken die gelbe und die rote LED. Die rote LED muss eingeschaltet bleiben.

Ich konnte leider trotz Einsatz von Minicom und tftp-Upload der Original-Firmware den Ausgangszustand nicht wiederherstellen. Die Station bootet nicht mehr durch. Sie bleibt im Bootvorgang hängen, oder landet in einer Boot-Schleife, je nach Original-Firmware-Version.

Anderswo hier im Forum las ich, dass man die Originalsoftware erst “beschneiden” müsse, bevor man sie zum Recovery über eine OpenWRT-Version (auch Gluon) drüberspielen könnte. Was ist daran wahr? Die BIOS-Routine des urescue prüft ja nach dem Entpacken die Integrität der Software und zeigt auch “OK” an. Wenn ich da nun einfach einen Block abschneide (mit dem neuen Bootloader), kann das ja auch nicht mehr funktionieren.

Ich hab es auch im unprotected Mode (protect off all) und einem "urescue -f " versucht. Das klappt leider auch nicht.

Ich habe Kontakt aufgenommen mit dem Ubiquiti-Support, die normalerweise nicht helfen. Mit etwas Glück bekommen wir nächste Woche trotzdem zumindest einen Tipp, wie man den Urzustand wiederherstellen kann.

Grüße
Tom


#24

Jetzt bin ich selber in die Falle geraten. Vor ein paar Monaten einen Nanostation Loco M2 gekauft, aber liegen gelassen wg. anderer Projekte. Dann hatte ich diesen zuletzt im Originalzustand mal zwischen Tür und Angel geflasht und alles lief glatt durch.
Letzte Woche dann mal schnell einen weiteren M2 geordert und gestern Abend mal schnell … gebrickt.

Am späten Abend natürlich geahnt das da was falsch war und auch einen Hinweis von Ubiquiti im Netz gefunden. Zu spät. Einige Images via TFTP konnte ich zwar einspielen, aber wie berichtet komme auch in in den Boot Loop. Bin mal gespannt ob Tom hier weiterkommt, sonst bohr ich ein Loch in das Gehäuse und verkauf das den Nachbarn als neueste Überwachungskamera am Haus.


#25

Any news?

Ich habe eine nanostation m2 loco (Neukauf) mit einem (falschen) FF image geflasht: einem “nanostation” anstatt “bullet” image. Danach kam sie nicht mehr hoch.

TFTP geht, da kann ich aber nur die aktuelle XW 5.6 einspielen, danach kommt sie ebenfalls nicht hoch. Das freifunk image oder ein 5.5 image von ubiquity wird erst gar nicht angenommen über TFTP.

How to unbrick?


#26

Da kann man problemlos via TFTP zurückflashen.

Dass Dir das passiert ist liegt vermutlich daran, dass Du keine Anleitungen gelesen hast.

Sorry, es wird Dir vermutlich nicht weiterhelfen.
Meiner Meinung nach sollte die Factory-FW derzeit besser nicht angeboten werden, zumindest nicht ohne deutliche Warnungen.
Wann der mögliche Fix zu einem Release wird: Ist noch offen.


#27

Mein Problem im Detail:

  • Nanostation locoM2 neu gekauft (vermutlich mit Firmware Version 5.6.x, nicht überprüft)
  • via Updatefunktion des Webinterfaces folgende Firmware geflasht:
    “ffrgb-ubiquiti-nanostation-m-20150322.bin” (das war wohl ein Fehler, ich hätte vorher die stock FW downgraden müssen auf 5.5x?)
  • nach reboot kein Kontakt über 192.168.1.1, LEDs blinken alle ~10 Sekunden kurz auf (bootloop?)
  • via 20sec Resetknopf drücken in den TFTP mode gewechselt und über die IP 192.168.1.20 versucht, diverse images zu flashen
  • gluon-ffrgb-bat15-snapshot-20150322-ubiquiti-bullet-m.bin
    ubiquiti’s Tool tftp2.exe meldet “unsuccessful”
  • ebenso bei
    gluon-ffrgb-bat15-v2015.2-ffrgb-11-g8cb6421-ubiquiti-bullet-m.bin,
    XW.v5.5.10-u2.28005.150723.1358.bin und
    XM.v5.5.11.28002.150723.1344.bin
  • was geht ist die aktuelle XM.v5.6.3.28591.151130.1749.bin und der direkte Vorgänger XM.v5.6.2.27929.150716.1201.bin
  • erfolgreicher flashvorgang, nach automatischem Reboot trotzdem kein Kontakt unter 192.168.1.20 möglich, alle 10 Sekunden wiederholt sich das LED blinkpattern (kurzes aufblitzen, ansonsten nur eine gelbe Power LED und flackernde gelbe LED daneben
  • versucht einen Reset durch 10 sec Reset-Knopf drücken -> keine Änderung.

Meine Frage:
-Welche Firmware kann ich noch versuchen? eine von openWRT direkt oder eine neuere von freifunk?
-Muss ich nach dem tftp flashen noch eine Art von Reset machen?


#28

versuch mal unsere Debrick Anleitung: https://wiki.md.freifunk.net/Anleitungen/Unbrick-Nanostation


#29

eine loco m5 lässt sich anscheinend mit der airOS for XW board firmware v5.6.3 direkt auf FF flachen

eine picostation wiederum nicht ;D


#30

Der Gluon-Master sollte sich seit ein paar Fixes vor 3 Tagen auch direkt von AirOS 5.6.x flashen lassen (Gluon-Ticket: https://github.com/freifunk-gluon/gluon/issues/663 ). Ich suche noch Tester, die bestätigen können, dass der Fix tatsächlich hilft, da ich nur eine einzige NS Loco M2 (XM) zum Testen hatte. Natürlich ist auch negatives Feedback hilfreich, wenn es noch immer Probleme gibt mit den Patches.

Wenn der Fix funktioniert, wird er auch in Gluon 2016.1.1 landen, das wahrscheinlich in den nächsten Tagen kommt (wir warten noch auf Feedback zu diesem und einem anderen Problem).


#31

Test mit einer Nanostation M2 (XM)
von AirOS auf den Gluon-Master von gestern abend (bb8d1783b38d1d1a1fcfb5500ef41d11cc978418): Schaut gut aus!

Mag noch jemand mit einer XW testen?




#32

Joar…

Es ist schon das zweite Mal, nachdem ich die Freifunk Moers Firmware auf eine Picostaiton M2-HP geflashed habe, dass sie gebricked ist.

Die einzige Firmware die eventuell mit Glück mal funktioniert ist die Bullet-M.

Firmware Quelle: http://images.freifunk-moers.de/

Per TFTP versuche ich also die Picostations wieder auf Original Firmware zu flashen, also hab ich mir die Firmware dazu runtergeladen: http://dl.ubnt.com/firmwares/XN-fw/v5.6.3/XM.v5.6.3.28591.151130.1749.bin
airOS for XM board firmware v5.6.3

Firmware wird auch ordnungsgemäß übertragen, nach dem flashen gibts aber eine Dauerbootschleife.

Irgendwo stand mal, man sollte es mit der alten Firmware Version versuchen, gibt es aber dort nicht.
Da ich zu glauben wage, dass das Board das gleiche ist wie in der Bullet M habe ich mich also dort bedient und diese geladen: http://dl.ubnt.com/firmwares/XN-fw/v5.5.11/XM.v5.5.11.28002.150723.1344.bin
XM.v5.5.11.28002.150723.1344.bin

Beim versuch das ganze per TFTP zu übertragen, kam nach wenigen Sekunden die Fehlermeldung " Error Code 512: Firmware check failed" und es passiert nichts.

Vorgehensweise beim flashen per TFTP:
Arbeittier: Apple MacBook mit OS X El Captitan.
Netzwerkeinstellungen:
IP des MacBook’s : 192.168.1.4

Reset Knopf der Picostation gedrückt und dabei das LAN Kabel eingesteckt, den Reset Knopf weitere 15 Sekunden gehalten, bis die Picostation in den TFTP Mode springt.

Software: Terminal
Schritte:
-> tftp
-> connect 192.168.1.20
-> binary
-> put XYZ.bin

Ich hoffe ich habe genügend Informationen geliefert und man kann mir weiter helfen :smiley:


#33

Das downgrade der org. Firmware hätte vor dem flashen der FF Firmware erfolgen müssen.

Tut mir leid aber die Kiste ist hin.


#34

Also muss ich bei der nächsten Picostation wie genau vorgehen?


#35

Schau mal hier:
https://ffnord.net/2015/11/30/ubiquiti.html


#36

Vielen Dank! :slight_smile: #20zeichen


#37

Haben die Dinger kein JTAG oder UART/TTL?


#38

Doch aber die neue Ubi Firmware hat ein ganz anderes Partitionslayout. Bügelt man die FF drüber zerschießt es den Bootloader.

Bisher hat noch keiner das Gerät wieder retten können. Hier im Forum findet man einiges zu dem Thema.


#39

Vielleicht würde sowas hier gehen (wenn man das richtige Partitionslayout hat)?
http://dhewett.co.uk/ubiquiti-uap-firmware-investigations-part-1/

EDIT: Hier hat es noch scheinbar noch jemand wieder zu einem funktionierenden DD-WRT zu kommen (aber von da nicht mehr weg)


#40

Dann flasht man über JTAG eben einen neuen… Wenn man irgendwo einen her kriegt.
Oder liege ich da jetzt falsch und es wurde mit dem zerschießen des Bootloaders auch die Hardware beschädigt?
Sollte doch eigentlich nicht so sein, oder?