Kurzprotokoll:
Nach einem gescheiterten Gluon-Update hatte ich das Vergnügen, das erste Mal eine Ubiquity Nanostation M2 „bricked“ vorzufinden.
Was schief gelaufen ist? Nicht mehr nachzuvollziehen, da das Update der Nachbarstation mit genau dem gleichen Image problemlos funktioniert hatte…
Symptom war: nach dem Booten flackert zwar LAN im Takt des ankommenden Traffics (Ping…), aber sonst keine Aktivität.
Der Reset-Knopf (hinter dem kleinen Löchlein) war durch den lokalen Benutzer schnell zerstört. (Das geht wohl vielen Leuten so, gäbe sonst nicht so viele Videos auf Youtube, die beschreiben wie man da einen neuen/anderen Taster einlötet).
Gerät war schnell geöffnet: Sticker mit einem scharfen Messer angehoben und abgezogen, Kreuzschraube mit einem PZ1 und etwas Nachdruck herausgedreht.
Zu dem Button: „mit Taster“ : Weder Config-Mode noch irgendein Failsafe-Mode (per „30-30-30“) erreichbar.
Dann einen Arduino-üblichen USB-RS232-Wandler (CMOS/TTL) an die Stiftleiste auf dem PCB des UBNT angeschlossen: Grundlage für das Malheur wurde dann im Bootlog klar: Irgendein Filesystem fehlt/kann nicht geladen werden. jeweils Kernel-.panic nach mehreren Dutzend Fehlversuchen, an verschiedenen Stellen ein FS zu finden.
(Vielen Dank an dieser Stelle an die Leute vom Chaotreff „Chaosdorf“ Düsseldorf, die mir kurzfristig mit einem solchen Adapter ausgeholfen haben, da ich ohne einen solchen unterwegs war und der lokale Fachhandel Preise dafür aufrief für die man eine komplette Nanostation „neu“ hätte kaufen können)
Nebenbemerkung: Sowohl diese USB-Adapter haben offensichtlich unterschiedliche Belegungen, selbst wenn sie optisch ähnlich aussehen. Aber es gibt ja zum Glück einen Silkscreen auf dem dem PCB. Aber -und das verwundert mich nun wirklich- scheint Ubiquity die Belegung der Stiftleiste mehrfach geändert zu haben. Und da ist die Beschriftung zumindest für mich nicht logisch neben den Kontakten platziert, so dass man ein muteres Ratespiel veranstalten darf, wo jetzt RxD sein mag. Ach ja, und Baudrate ist auch nicht wie an vielen Stellen im Netz behauptet 9600, sondern -wie eigentlich auch erwartet- 115200.
Anway: Hat dann geklappt mit dem Debricken.
Interessessant finde ich, dass der Dateitransfer hier genau umgekehrt initiert wird wie bei den TP-Links.
Man logt sich zwar mit der RS232-Console ein und bricht dort dem Bootprozess mit Strg-C/ESC ab. (was jetzt gewirkt hat: Ich weiss es nimmer.)
Man begibt sich dann in den rescue/recovery-Mode mit einem einzigen, parameterlosen Befehl. Der tut aber nichts weiter, als die Nanostation in einen TFTP-Server zu erwandeln.
Das File was man dann manuell per tftp-client auf die 192.168.1.20 schiebt, das wird geladen und ausgeführt.
Also kein Tippen von 3-4 Befehlen im Terminal, sondern dort nur ein Befehl und der Rest dann auf der Kommandozeile des eigenen Rechners.
Danach war dann erstmal wieder die ubiquity-Firmware drin.
Dann nochmal das FF-Image per Weboberfläche drüber geladen und dann lief auch dieser Node.
(Falls jemand noch Details wissen möchte, ich unterfüttere die einzelnen Punkte gern mit Bildern/Weblinks.)