Hallo DL3DCF,
vielen Dank für Deine Beschreibung es hat alles geklappt.
Resetbutton am Netzteil für 10 sec. gedrückt, dann kurz losgelassen und für 30 sec. gedrückt.
Büroklammer wie adorfer vorgeschlagen reicht.
Anschließend über tftp die Firmware eingespielt.
Läuft! 
P.S: gibt es eine deutsche Beschreibung für die Loco M2.
Ich sehe rote und orange Lichter obwohl ich Internetzugang über die Loco M2 habe.
Die Stationen lassen sich auch über den Reset-Taster im Injektor in den Config-Mode oder in den TFTP-Mode versetzen. Man sieht dannleider nicht anhand der Lichtorgel, o es geklappt hat. Aber da hilft dann auch ein Ping.
Guten Morgen!
Vielleicht übersehe ich ja etwas, aber was unterscheidet jetzt Deine Antwort von dem was schon x mal vorher oben im Thread geschrieben stand?
Sorry,
ich habe danach gesucht, ob es inzwischen eine Lösung für das Problem
gibt (nicht mehr booten können).
Dabei habe ich nur den Ausschnitt erwischt per Google…
Aber ich hänge hier jetzt immer noch in der Tinte mit sieben Nano Loco
M2, die alle nch FF-Firmware schreien. Die erste habe ich geschreddert.
Mittels Minicom kann ich dabei zusehen, wie die Loco zu booten versuchtr:
U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0, eth1
Board: Ubiquiti Networks XM board (rev 1.2 e0a2)
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
Image Name: MIPS Ubiquiti Linux-2.6.32.65
Created: 2015-07-16 9:01:51 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 1004345 Bytes = 980.8 kB
Load Address: 80002000
Entry Point: 80002000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Booting...
Dabei gerät sie in die besagte Boot-Schleife.
Grüße und Guten Rutsch
Tom
Hatte das gleiche Problem. Link
Wie genau tun sie das?
Der Weg „alte Ubiquity-FW flashen“ und dann erst im zweiten Step FF-Firmware einspielen scheitert also?
Wenn ja wo? Dass auch mit der alten UBNT-FW der Bootloader die FF-Fiw zwar nimmt, aber dann nicht akzeptiert und dann in der Bootloop hängt?
Na, Du Witzbold…
Sechse stehen in der Kiste und warten darauf, dass ich eine Lösung finde.
Die siebte liegt aufgeschraubt und halbtot auf meinem Tisch und lässt
sich nicht mehr dazu bewegen, nach dem Rück-Flashen wieder zu booten, bzw:
„urescue -f“ hat nicht funktioniert, sondern nur „urescue“
Erst nachdem ich „protect off all“ benutzt hatte, konnte ich auch
„urescue -f“ aufrufen
Die Ausgaben dazu in der Minicom-Konsole sehen dann auch tatsächlich
etwas anders aus.
Genützt hat es aber bisher trotzdem nichts. Ich bekomme weder den
Urzustand wiederhergestellt, noch eine Software-Version älter…
Übrigens habe ich auch keine „redboot“-Shell bekommen, wie vielfach im
Netz beschrieben, sondern nur ein Prompt mit "ar7240> "
und der folgenden Hilfe:
ar7240> help
? - alias for ‚help‘
base - print or set address offset
boot - boot default, i.e., run ‚bootcmd‘
bootd - boot default, i.e., run ‚bootcmd‘
bootelf - Boot from an ELF image in memory
bootm - boot application image from memory
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address ‚addr‘
help - print online help
iminfo - print header information for application image
imls - list all images found in flash
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing)
mtdparts- define flash/nand partitions
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
autoscr - run script from memory
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sleep - delay execution for some time
tftpboot- boot image via network using TFTP protocol
urescue - start TFTP server and wait for firmware
version - print monitor version
Die kann man ja auch an beliebig vielen Stellen im Web finden…
Wenn im Freifunk-Forum keiner mehr einen Tipp hat, schreibe ich dem
Ubiquiti-Support. Wenn die weiter verkaufen wollen, müssten sie doch
eigentlich auch die passenden Hinweise rausgeben, oder?
Versuch macht klug.
Guten Rutsch
Tom
Ich hätte Interesse an einer der betroffenen Nanostations. Gern auch im Tausch gegen eine ältere auf der schon irgend ein Gluon dreht.
Ist da evtl kurzfristig in NRW was zu machen?
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
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.
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
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
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
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).
kann das sein, dass ich die Stock-Firmware erst trimmen muss, bevor ich die Gluon-FW mittels tftp damit überschreibe?
Grüße
Tom
nein das geht auch so wenn du den downgrade auf 5.5.x gemacht hast
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
Hallo,
ich habe im April leider das gleiche Problem.
Hat jemand eine Lösung dazu?
Grüße
Axel
Schon mal probiert mit TFTP auf die alte Stock zurückzukehren?
Vermute ich: „Ja“. Denn darauf bezieht sich Axel doch.
(Das Thema habe ich mal zusammen gelegt, weil es alles „das gleiche“ ist.)