Gebrickter 842 - aufpäppeln oder Gnadenschuss?

Hallo,

nachdem einer meiner 842 beim Update auf 0.5.12 gebrickt wurde, kam ich jetzt dazu ihn mir mal näher vorzunehmen.

Failsafe recovery hat weder über über Freifunknetz noch lokal am Raspberry funktioniert. Gestern hab ich dann die Kiste geöffnet und eine Pfostenleiste an die serielle Schnittstelle gelötet. Noch mal nachgemessen ob die wirklich mit 3,3 V arbeitet (ja, tut sie) und dann mit der Seriellen des Raspberry verbunden.

Das Ergebnis sieht nicht ermutigend aus. Im Router tut sich zwar noch was, aber ich komme nicht auf die Konsole.
Es laufen Systemmeldungen auf und so ziemlich die letzte ist eine “Kernel Panic”.

Die letzten Lebenszeichen

[    7.400000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not 
found at 0x0061004c: 0x2c00 instead
[    7.410000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not 
found at 0x00610050: 0x1c00 instead
[    7.420000] jffs2: Further such events for this erase block will not 
be printed
[    7.440000] jffs2: Empty flash at 0x00611094 ends at 0x006110a8
[    7.440000] jffs2: CLEANMARKER node found at 0x006110b0, not first 
node in block (0x00610000)
[    7.480000] jffs2: notice: (1) jffs2_build_xattr_subsystem: complete 
building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of 
xref (0 dead, 0 orphan) found.
[    7.490000] VFS: Mounted root (jffs2 filesystem) readonly on device 
31:2.
[    7.500000] Freeing unused kernel memory: 268K (8038d000 - 803d0000)
[    7.510000] Kernel panic - not syncing: No working init found.  Try 
passing init= option to kernel. See Linux Documentation/init.txt for 
guidance.
[    7.510000] ---[ end Kernel panic - not syncing: No working init 
found.  Try passing init= option to kernel. See Linux 
Documentation/init.txt for guidance.
[   82.560000] random: nonblocking pool is initialized

Den kompletten mitgeschnittenen Text gibt es auf https://paste.ffrn.de/?eab54b65b1bc0fb0#uO1JS0Vw0vwfSoNn/7Iq5GK+UaI4Vl1vz8g/Li7Ie0s=

Das ganze beim “normalen” Start. Beim Start mit gedrückter Reset-Taste kommt nur Datenmüll über die Serielle.

Der Router war gleichzeitig per Netzwerkkabel mit dem Raspberry verbunden. Raspberry auf 192.168.0.66, aber eine Anmeldung von 192.168.0.86 im Failsafe-Mode war per TCPDUMP nicht festzustellen.

Gibt es noch Hoffnung für den Patienten oder ist er jetzt Elektronikschrott?

raff

Nicht wegwerfen, den bekommt man bestimmt wieder hin. Irgendwas mit deiner seriellen Schnittstelle stimmt nicht, da ist viel zu viel Müll dazwischen. Mal eine andere Gegenstelle probiert?

1 „Gefällt mir“

Der Datenmüll über die serielle Schnittstelle ist mir auch aufgefallen. Ich hab es aber eher als Symptom angesehen. Reproduzierbar passiert es nur am Anfang, Zeitstempel 0,000000 bis 0,700000. Ab 0,700000 läuft das Protokoll ohne Fehler durch. Genau zu diesem Zeitpunkt wird nach den Meldungen die serielle Schnittstelle des 842 offenbar neu initialisiert. Könnte sein, das sie vorher in einem undefinierten Zustand läuft.

Deshalb vermute ich die Ursache erst mal nicht in der Schnittstelle des Raspberry. Ein serielles GPS und ein e-ink Display laufen an ihr ohne Fehler.

Eine andere Gegenstelle konnte ich noch nicht testen. Da muss ich erst mal sehen was ich (außer einem anderen Raspberry) noch zur Verfügung habe.

Allerdings ist das Ganze nur ein fliegender Aufbau.

Könnte also auch an Interferenzen liegen. Keine Ahnung was der 842 beim INIT über die Antennenkabel von sich gibt.

Das hat nichts zu sagen. Ich habe hier auf der Arbeit manchmal sogar mit recht hochwertiger Hardware solche Artefakte auf der Seriellen Schnittstelle. Oft hat es was mit Ausgleichsströmen auf der Masse zu tun, manchmal sind sie auch nach einem Power-Cycle des zu testenden Gerätes weg.

Evtl mal Masse vom RPi und vom 842-er am Netzteil verbinden.

Das werde ich versuchen.Aber eigentlich ist das aus meiner Sicht ein Nebenschauplatz. Nachdem die serielle Schnittstelle des 842 bei 0.70000 initialisiert wird, läuft die Verbindung ja fehlerlos.

Was ich suche sind Informationen wie ich die Kiste dazu bringe Befehle anzunehmen. Der automatische Recovery über TFTP hat nicht funktioniert, über Netzwerk komm ich nicht ran und bei der seriellen Schnittstelle komme ich auch nicht auf die Konsole.
Das System ist ja nicht tot. Irgendein Programm wird abgearbeitet. Dummerweise nicht das von mir gewollte.

Kann ich das System resetten ohne es vom Strom zu trennen? Die Reset-Taste an der Rückseite zeigt keine Reaktion. Irgendeine Möglichkeit intern ein Reset herbeizuführen?

Im Failsafemode kommt bei mir über die serielle ja kein Log. Dafür habe ich Aktivität auf der Netzwerkverbindung. Wenn ich TCPDUMP richtig interpretiere könnten das DHCP Anfragen sein. Eigentlich sollte sich der 842 in diesem Fall mit fester IP 192.168.0.86 anmelden.
Gibt es da noch Möglichkeiten?

Das ist in der Tat sehr seltsam, in der Zeile vorher wird die serielle Schnittstelle vom Kernel initialisiert. Die Baudrate stimmt jedoch, denn vorher sind auch schon korrekte Fetzen von Meldungen zu erkennen. Stimmt vielleicht irgendwas am Handshake nicht? 8N1?

Welche HW-Version ist Dein 842er?

https://wiki.openwrt.org/toh/tp-link/tl-wr842nd#serial_connector

To get the serial connection work reliably, you may have to connect a 10k pullup resistor between the TX and the 3.3V pin (same problem as described in TL-MR3420). For some users the V2.1 models did not need this pullup resistor.

The TX pin is connected via a 10k resistor to ground and via a 100nF capacitor to the serial output of the SoC. This gives a 2.5Vpp swing centered on ground. While this may work with some serial adapters, it is on the low side for most. An advantage of this connection scheme is that it protects the serial output to some degree.

Zuerst die gute Nachricht - Die Kiste funktioniert wieder!

Die schlechte Nachricht - Ich hab keine Ahnung warum.

Da ich mit der Konsole nicht weitergekommen bin, hab ich mich doch noch etwas mit dem Failsafe-Modus beschäftigt. Nachdem ich am Raspberry TCPDUMP im ASCII-Modus benutzt habe, konnte ich sehen das der Router unter der Adresse 192.168.0.86 tatsächlich die entsprechende recovery.bin anfordert. Komischerweise nur, wenn ich am Router in einen der gelben Ports gegangen bin. Vom Raspberry wurde ihm die Datei aber nicht geliefert, obwohl eth0 auf 192.168.0.66 eingestellt war und ATFTPD lief. Hab zuerst auf ATFTPD getippt, konnte aber keinen Fehler finden.
Nach einigen Versuchen, die alle nichts brachten, hatte ich aber einmal nach dem Neustart des Raspberry vergessen der eth0 die Adresse 192.168.0.66 zuzuweisen bevor der Router lief.
Als ich also per “ip addr add 192.168.0.66/24 dev eth0” die Adresse umgestellt habe, während der Router schon fleissig die recovery.bin angefordert hat, funktionierte es plötzlich. Es gab hektische Aktivität über Ethernet und parallel Logmeldungen auf der Konsole. Nach einem Neustart des Routers konnte ich über TCPDUMP am Raspberry sehen, das eth0 per DHCP eine Adresse im 192.168.1.X-Bereich zugewiesen bekam und ich konnte unter 192.168.1.1 die Bedienoberfläche des Routers aufrufen.

Erklären kann ich das ganze nicht, es könnte aber mit einem Hinweis unter
https://wiki.openwrt.org/toh/tp-link/tl-wr842nd#recovery_v2
zusammenhängen:

Router must be in recovery mode before starting tftpd server, otherwise it might have problems trying to bind to the PC network interface.

Jedenfalls läuft der Knoten wieder und hat inzwischen auch das Autoupdate auf 0.5.13 erfolgreich überstanden. Dann kann ich mich jetzt mal mit der Nanostation beschäftigen, die hier die Arbeit verweigert.

1 „Gefällt mir“

Für direkte Verbindung am Netzteil müsste ich die Steckernetzteile öffnen. Das ist mir dann doch zuviel Aufwand.
Als Ersatz hab ich zusätzlich noch mal die blanken Gehäuse der USB-Schnittstellen an Router und Raspberry verbunden. Das hat aber keinen Unterschied gemacht.

Den Hinweis mit dem 10k Widerstand hatte ich gelesen aber übergangen, da die Schnittstelle ja lesbare Daten ausspuckte. Da die Kiste wieder arbeitet ist es auch nicht mehr nötig es auszuprobieren.
Zumindest war es offenbar nicht der Grund, dass die Konsole nicht auftauchte. Nachdem der Router neu geflasht war, hat er nach den Logmeldungen auch den Promt angezeigt.