[Problem] 4040 Recovery findet Box nicht mehr, je nach LAN Port blinken andere LEDs

[elfri]

Hallo zusammen.
Habe eine 4040, die ich mit der Recovery 7.14 konfrontiert habe, nach AVM-Anleitung.
Ergebnis: nicht mehr erreichbar, weiteres Recovery findet sie nicht mehr, LEDs blinken einzeln, je nach LAN-Port andere wie ich festgestellt habe.

Im Detail:
Recovery 7.14 hat im ersten Anlauf die Box gefunden, sah gut aus. Ernüchterung: nachdem der Fortschrittsbalken für "lösche MTD1" voll war blieb das Tool genau da stehen. Nach 2 Stunden habe ich sie vom Strom getrennt.

Beim nächsten Versuch schien erstmal nichts mehr zu gehen. Wenn ich ihr Strom gab leuchtete oder blinkte jedes Mal eine andere LED, meist nur eine, mal auch gar keine.
===================================================
EDIT 24-05-2020:
Neuen Thread aufgemacht, da wir jetzt beim "Rom Backen" sind und hier unten viel "OT" mit drin steckt (was ist denn nun RS232 und was ist TTL... ;-) )
Alles, was wir hier in diesem unten besprachen führte zu keinen Erfolgen.
===================================================

Irgendwo las ich: Netzteil-Problem. Na, eigentlich nicht, lief ja mit dem Netzteil bis dato.
Aber gut, das "Fette" von der 7490 (2.4A statt geforderter 1.4A) verwendet.
Recovery nochmal drauf gejagt. Leider vergessen welcher Port das war. Jedenfalls schnurrte das Recovery 7.14 diesmal durch. Am Ende behauptete es, erfolgreich gewesen zu sein. Und dann ging "Power" aus und die Box bliebt dunkel. Hmmmm?? Soll das so? Strom ab.

Kurz gewartet, Saft dran. INFO LED blinkt rot. Nicht gut. Nochmal probiert, immer blinkt irgend eine andere LED. Aber Recovery mag nicht mehr. Mist.

Heute nochmal bei. Tipp gefunden dass ein Downgrade mit Recovery auf 7.01 zuverlässiger sei. Findet die Box nicht.

Je nach verwendetem LAN Port blinkt tatsächlich eine andere LED nachdem ich Saft gebe, aber Recovery (weder 7.14 noch 7.01) findet sie nicht
LAN4: “LAN” leuchtet einmal grün, danach blinkt “INFO” unregelmäßg grün mit sehr kurzen Unterbrechungen.
LAN3: “POWER” blinkt grün, unregelmäßig.
LAN2: “INTERNET” leuchtet einmal kurz grün, dann alles dunkel.
LAN1:
“W-LAN” leuchtet einmal grün auf, dann blinkt “INFO” rot. Nach einer Weile hört “INFO” auf, und “W-LAN” fängt an wild grün zu blinken. Nach ein paar Sekunden ist “W-LAN” dann fast dauernd an, zuckt alle paar Sekunden mal auf “aus”. Häufigkeit wird mehr, dann wieder weniger, dann wieder fast dauernd an.
Das macht sie dann Minuten lang...
Dann bei weiterhin aktivem Strom nochmal das Recovery gestartet. Scheint nun so: Solange es such scheint WLAN zu blinken. Hört die Suche auf, bleibt WLAN grün.
Das mit dem "Blinkt beim Suchen" kann auch bei LAN4 und LAN3 sein, habe ich (noch) nicht länger probiert.

Puh.... und Nu?
Jemand noch einen Tipp was ich tun kann? Nächster Versuch wäre nochmal mit Switch dazwischen. Aber da er bei den Versuchen oben die Box immer schnell erkannt hat ... wenig Hoffnung.

Linux, W10, einige Kenntnisse, Lötkolben... und Ehrgeiz...alles verfügbar - nur leider kein Kaufbeleg der Fritte mehr (die laut Seriennummer K362... in K=2019, Woche 36, Dienstag = 3.9.2019 hergestellt wurde... kein Jahr auf dem Buckel )

Ich hau mich erstmal hin
n8.

 

[PeterPawn]

Das Problem ist vermutlich, daß die Dakota-basierten Boxen nicht wirklich gut "untersucht" sind bisher - und wenn, dann eher die 7520 und 7530.

Die 4040 hat wohl kaum einer und damit fehlen schon die Vergleichsmöglichkeiten, wie sich die LEDs normalerweise verhalten sollten. Oder kannst Du sicher sagen, daß das vor dem Update bei der 4040 genauso war, wie bei anderen FRITZ!Box-Modellen? Kennst Du andere (aktuelle) Boxen?

Ich würde es ja mal versuchen wollen, Dir ein paar Tipps zu geben ... nur kenne ich eben die 4040 nicht selbst - und das "Lampenspiel" verwirrt mich vollkommen, weil das eigentlich bei anderen Modellen nicht "zum Plan" gehört, daß sich die LEDs in Abhängigkeit von den aktivierten Ports ändern.

Deine Erzählung klingt ja irgendwo so, als wäre für jeden Port eine andere LED zuständig ... was passiert denn, wenn Du an zwei Ports eine (aktive) Ethernet-Verbindung hast? Leuchten dann beide LEDs kurz auf? Wenn ja und Du nicht definitiv weiß, daß das zuvor nicht so war, würde ich darauf tippen, daß AVM bei der 4040 irgendwelche zusätzlichen Blinksignale in EVA probiert hat und die "Aussagen" der LEDs erst mal ignorieren.

Stattdessen einen Switch (am besten mit Port-Mirroring, was dann zum Mitschnitt genutzt wird) zwischen Box und PC schalten und die Vermutung, daß das Blinken der WLAN-LED mit der Suche nach der Box zusammenhängt, überprüfen ... dazu kann man (Linux hast Du ja, W10 notfalls auch) mit diesen Tools: https://www.ip-phone-forum.de/threa...kript-dateien-aus-yourfritz-eva_tools.298591/ dieselben Pakete erzeugen, mit denen auch das Recovery-Programm nach der Box sucht und mit einem Paketmitschnitt auf dem verwendeten PC, kann man dann auch gleich noch sehen, ob die Box irgendwie antwortet (UDP-Pakete an Port 5035).

Wenn man das mit dem Kabel in einer Ethernet-Buchse macht, die nicht "LAN1" (wo Du das ja bisher beobachtet hast mit der blinkenden WLAN-LED) ist, kriegt man vielleicht heraus, ob es tatsächlich einen direkten Zusammenhang gibt und u.U. sogar, welcher das genau ist. Wenn die Box sogar antworten sollte, kann man auch (von Hand) eine FTP-Verbindung zu der entsprechenden Adresse aufbauen.

=================================================================

Wenn Du bisher nur mit dem Recovery-Programm von AVM gearbeitet hast und auf dem verwendeten PC nicht mehrere FRITZ!Boxen "verarztet" wurden, kann man auch versuchen, über das "Gedächtnis" des Recovery-Programms noch ein paar Infos zu sammeln.

Die Basis des AVM-Programms ist ziemlich alt und so versucht das Programm auch, bei jedem Lauf eine Datei "environment.log" und eine Datei "ftp.log" im Windows-Verzeichnis zu speichern. Während es die "ftp.log" tatsächlich nur einmal gibt und bei jedem Anlauf eine neue Datei geschrieben wird, werden bei der "environment.log" Kopien angelegt und zwar nach dem Schema "environment_XX.log", wobei für "XX" die zwanzig Werte von "00" bis "19" durchprobiert werden. Findet sich dabei ein "freier Slot", wird die Datei unter diesem Namen gespeichert und nicht überschrieben. Ist kein "Platz" mehr frei bei den Namen, überschreibt jeder neue Anlauf des Recovery-Programms auch die "environment.log".

Ansonsten steht in der "environment.log" eben genau das, was das Recovery-Programm von der Box als Ausgabe von "RETR env" gelesen hat und in der "ftp.log" neben dem eigentlichen Dialog auch noch ein paar Zusatz-Infos ... u.a. die, wie das Recovery-Programm das Netzwerk-Interface konfiguriert hat. Auch wenn das Recovery-Programm die Box nicht findet, wäre es schon interessant, was in der "ftp.log" dazu steht, wie es nach ihr sucht. Auch der Kontrollblick in das letzte, von der Box erfolgreich gelesene Environment kann nicht schaden - da sind einige wichtige Infos drin, u.a. die Versionsnummer der letzten, erfolgreich gestarteten FRITZ!OS-Version und wenn Du hier mit zwei verschiedenen Versionen unterwegs warst und sich beide von der eigentlich installierten Firmware unterscheiden, kann man damit auch schon mal schlußfolgern, ob überhaupt irgendeine Schreiboperation im Flash erfolgreich war und ein System gestartet wurde - das Eintragen der Versionsnummer erfolgt ziemlich direkt beim Start des Systems.

Wobei das mit den Dateien im Windows-Verzeichnis halt auch nicht so direkt stimmt ... solches Schreiben in das Windows-Verzeichnis war zwar früher Usus, aber natürlich eine einzige Sicherheitslücke und so hat Microsoft dann irgendwann mal begonnen, die Zugriffe der Benutzer und der von ihnen gestarteten Programme auf das Windows-Verzeichnis zu virtualisieren und die Änderungen gar nicht wirklich am Windows-Verzeichnis vorzunehmen, sondern in einem gesonderten Pfad unterhalb des benutzereigenen Verzeichnisbaum im System. Das ist normalerweise dann "C:\Users\<benutzer>\AppData\Local\VirtualStore\Windows\", wo man nach den erwähnten Dateien suchen müßte. Startet man das Recovery-Programm über "Run as administrator", landen die Dateien aber auch tatsächlich im Windows-Verzeichnis - keine empfehlenswerte Idee für die Zukunft, aber u.U. auch eine zweite Stelle, wo man nach älteren Dateien suchen könnte, falls man das Programm in der Vergangenheit mal auf diesem Weg gestartet hatte.

Für weitere Ideen muß man erst mal abwarten, was Du noch so an Infos zusammentragen kannst ... reagiert der Bootloader tatsächlich nicht auf das Broadcast-Paket, mit dem das AVM-Recovery-Programm oder auch meine Skript-Dateien nach ihm suchen, sähe ich schwarz.

Aber wir hatten hier auch schon Bootloader, die wegen gelöschter Einstellungen (was das Recovery-Programm halt auch mitmacht) nicht mehr aus dem Kniff kommen wollten und anstelle einer korrekten ARP-Antwort ein Paket mit einer falschen MAC-Adresse gesendet haben (das ist bei mind. einer Version des Bootloaders der 6490 reproduzierbar). Wenn es irgendetwas in dieser Richtung sein sollte, braucht es zwar Geduld und Spucke, aber dann gäbe es noch Chancen - aber da reagierte dann auch der Bootloader noch auf die Broadcast-Pakete und man sah schon daran, daß er nicht wirklich "tot" war.

Wenn Dein lustiges Lichterspiel am Ende tatsächlich auch irgendwie damit zusammenhängen sollte, daß die Box keine vernünftigen Einstellungen mehr in den TFFS-Partitionen hat (die hat ja wohl 32 MB SPI-Flash und damit sicherlich auch wieder "legacy TFFS" mit zwei Partitionen), dann wäre es auch nicht verwunderlich, daß das bisher noch keiner bei sich so gesehen hat ... solche Fälle werden wohl nicht so oft auftreten. Aber gerade auch für so einen Fall bräuchte man ziemlich dringend dann ein älteres Environment - daher würde ich mit der Suche nach den o.a. Dateien beginnen und alles, was ich da finden kann, erst einmal in Sicherheit bringen - auch wenn da Dubletten drin sein sollten.

Ideal wäre es natürlich, wenn sich hier noch ein anderer mit demselben Modell melden würde, der Dir (bzw. uns) berichten könnte, wie das bei einem "normalen Start" der Box abläuft ... ich nehme mal nicht an, daß Du das schon selbst mal soo bewußt angesehen hast, daß Du weißt, wie es eigentlich aussehen sollte?

Und ich will ja nicht neugierig sein ... aber warum wolltest Du denn mit dem Recovery-Programm auf die Box losgehen? Gab es vorher schon irgendwelche Auffälligkeiten, denen Du mit dem Recovery-Lauf zuleibe rücken wolltest? Oder war das "nur mal so, um mal wieder Ordnung zu machen"? Vorherige Fehler wären natürlich auch ein mögliches Zeichen für ein "echtes Problem" ... deshalb frage ich danach.

 

[NDiIPP]

Spoiler: OffTopic

Die 4040 hat wohl kaum einer und damit fehlen schon die Vergleichsmöglichkeiten, ...

Zumindest hier im Forum dem Anschein nach. Bei einigen anderen "Interessengruppen" soll die 4040, dem Hörensagen nach, jedoch beliebt sein (bspw. Freifunk), dank guter xWRT-Kompatibilität/Unterstützung. Quasi als Alternative zu einigen TP-Link Geräten, wo man beim Erwerb u.U. auch auf die HW-Rev. genauer schauen muss (was nicht immer ganz einfach ist bzw. tw. noch nicht einmal möglich ist).

 

[elfri]

Hallo zusammen.
Erstmal 1000 Dank für die Mühe der Skripte, der ausführlichen fallbezogenen Antwort - und überhaupt!
Bin so ziemlich allem nachgegangen was PeterPawn erklärte, verlinkte, erwähnte.
Das mit den Freifunk/open-wrt-Kollegen hatte ich auch schon gesehen. Aber ich fürchte, die muss ich nicht mehr belästigen gehen.

Ihr müsst alles Folgende nicht lesen, denn im Ergebnis ist sie leider einfach tot würde ich folgern.
Ganz kurz: Alle ihre Ports scheinen noch elektrisch zu funzen, LEDs an Switch und Fritte (sofern zugeordnet, 3 sind es offenbar) blinken munter, aber sonst nullkommanix. Power und Info habe ich nicht mehr gesehen bei all meinen Tests.

Also wenn nicht einer einen heißen Tipp hat wie ich diese nicht mal ein Jahr alte Müllhalde ohne Rechnung von AVM getauscht bekomme... braucht einer einen Briefbeschwerer oder will was "rumlöten" üben?

Also, spart euch gern das Lesen, es sei denn, ihr habt zu viel Zeit

You have been warned

Spoiler: Warum Recovery?

Na das übliche. Gebraucht gekauft, Verkäufer sagt "komme nicht mehr drauf und habe keine Laptops mit LAN-Buchse mehr im Haus".
Ich mit Laptop hin, mach ma an. LEDs gehen an, Power, irgendwas blinkt, sah ungefähr aus wie bei meiner 7490, "ziemlich unverdächtig". Also auch nicht gemerkt was, denn der eigentliche Test kam ja noch.
Kurz gewartet bis Power und was da noch blinkte "an" ist. Ah, gebootet. Sieht doch normal aus.
LAN Kabel ran, IP bekommen, Web-Interface kommt - na geht doch, der Rest sollte doch ein Kinderspiel sein. Mitgenommen.
Daheim an den Strom, wieder die "normale" (glaube ich) "Lichtorgel-Sequenz". Laptop schon daneben um einen Reset zu machen über "Passwort vergessen", oder halt wenn das nicht geht Recovery.
Denke mir: muss doch aber auch ohne LAN gehen. WLAN-Kennwort hab ich zwar nicht, aber brauch ich doch nicht kennen, hat doch 'ne WPS-Taste! Probierste die einfach mal.
Also WPS gedrückt - WLAN blinkt... und geht dann aus. hmmm? Soll das so?
LAN ran. Keine Reaktion, keine LED, keine IP bekommen. HÄ? DAS soll so nich.
Strom weg, warten, Strom ran. Tot, kein Licht, nix. HÄ?
Strom weg, warten, Strom ran, Power sagt nichts, info blinkt grün. HÄ?
Sch**. hat sie doch irgendwas?!
Also Recovery.
Der Rest steht oben...

Spoiler: War da schon mal einer drin? Füße ab Werk? - Nur so aus Neugier

Falls jemand mitliest der eine 4040 hat, bitte mal eine Kleinigkeit checken:
Zum öffnen der Fritte muss man die beiden vorderen Gummi-Füße entfernen. Bitte mal machen. Mehr nicht.
Will wissen: ist einer davon mit einem "langen Pröppel" nur gesteckt, und der andere ohne "Pröppel" geklebt wie so ein "Möbel-Nupsi" vom schwedischen Möbelhaus?
Wenn beide einen "Steck-Pröppel" haben war bei mir wohl schon mal einer dran und hat den Pröppel verloren und einen Möbebumper genommen.

Spoiler: Log files vom W10 Rechner

Das muss man erstmal wissen. Und warum zum Teufel behält er nicht mehrere FTP logs.
Das letzte was ich habe sagt ungefähr nix. Da habe ich zuletzt nochmal die Recov-7.14 probiert, nachdem die 7.01 ja nichts mehr gefunden hat.

0:06:845: 2.00 gitbuild:3524e9a
0:06:845: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=0
0:06:845: recover-firmware-id:        227
0:06:845: recover-firmware-version:    de-en-es-it-fr-pl.155.07.14
[**]
0:07:164: prefered dhcp-adapter 0x2:
0:07:164: check adapter(Intel(R) Ethernet Connection I219-LM) adapter 0x2: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:07:219: can't add ipaddress (192.168.178.2 - 255.255.255.0) on adapter=2 Error=5
[der Teil von ** bis hier wiederholt sich 11 Mal]
0:09:890: prefered dhcp-adapter 0x2:
0:09:890: check adapter(Intel(R) Ethernet Connection I219-LM) adapter 0x2: Ip: 169.254.42.12(255.255.0.0) (dhcp)
0:09:890: prefered dhcp-adapter (2) with ip 169.254.42.12 found: first choice
0:10:026: search on addr: 169.254.42.1
[hier hat er dann scheinbar ohne weitere Einträge 28 Sekunden gewartet!? Und ich glaube dann habe ich "abbrechen" gedrückt]
0:38:905: exit:    errorcode=-1
0:38:905: ----EOF---

environment_xx.log hab ich 4 vom Tag davor. Das, was zur selben Zeit wie das FTP log oben entstand ist 0 byte groß - wundert ja nicht.
Die env.logs die ich habe sind alle identisch wie folgt (xxxxx - anonymisiert, da sind korrekte Daten)

HWRevision            227
HWSubRevision         4
ProductID             Fritz_Box_HW227
SerialNumber          K362xxxxxxxxxxx [anonymisiert]
annex                 Ohne
autoload              yes
bootloaderVersion     1.3243
country               99
crash                 [0]1eb9ee17,5c023d4f,1[1]0,0,0[2]0,0,0[3]0,0,0
firstfreeaddress      0x8817DA88
firmware_info         155.06.83
firmware_version      avme
flashsize             nor_size=0MB sflash_size=32768KB nand_size=0MB
jffs2_size            16
language              en
maca                  7C:xx:xx:xx:xx:xx [anonymisiert]
macb                  7C:xx:xx:xx:xx:xx
macwlan               7C:xx:xx:xx:xx:xx
macwlan2              7C:xx:xx:xx:xx:xx
macdsl                7C:xx:xx:xx:xx:xx
memsize               0x10000000
mtd0                  0x2000000,0x2000000
mtd1                  0x220000,0x2000000
mtd2                  0x0,0x120000
mtd3                  0x120000,0x1A0000
mtd4                  0x1A0000,0x220000
my_ipaddress          169.254.42.1
prompt                Eva_AVM
tr069_passphrase      xxxxxxxxxxxx [anonymisiert]
tr069_serial          xxxxxx-xxxxxxxxxxxx [anonymisiert]
usb_board_mac         7C:xx:xx:xx:xx:xx [anonymisiert]
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         7C:xx:xx:xx:xx:xx 
webgui_pass           xxxxxxxxxx
wlan_key              xxxxxxxxxxxxxxxxxxx
wlan_ssid             FRITZ!Box#4040#KY

Spoiler: LED-Tests

So, jetzt zum Rest vom Fest. Viel probiert.

Ein paar Abkürzungen:
Fritzbox = Fritte = F.
LEDs der F: Power=P; internNet=N; Wlan=W; Lan=L; Info=I

Test mit 100MBit 5Port-Switch gemacht. Details unten.

Bei allen folgenden Tests ist der switch dauernd unter Spannung. Nur die F wird geschaltet.

1. Test: Alles verkabeln, Zuordnung ermitteln
Switch Port 1 an Fritz LAN 1 usw für LAN1-4
Switch Port 5 an Fritz WAN
- Power auf Switch und Fritte.
- Nach ca. 2s leuchten N+W+L einmal auf, nach weiteren 2s bleiben sie dauerhaft an
- P+I bleiben die ganze Zeit aus
- Nacheinander die LAN-Kabel am Switch raus("!") und wieder rein:
- !L1 => W aus; L1 => W an
- !L2 => N aus; L2 => N an
- L3 macht keinen Unterschied*
- !L4 => L aus; L4 => L an.
- W macht keinen Unterschied*
*: an der F keine LED, aber am Switch gehen die LEDs aus / an => L3/W "leben", haben aber keine LED auf der F zugeordnet
F mit allen Kabeln bis auf L3 stehen gelassen. Nach ein paar Minuten gehen kurz alle Lichter an F und Switch aus, an, aus, an, bleiben dann an.
Irgendwann geht dann W aus, N und L bleiben aber wieder konstant an.

2. Mehrere unterschiedliche Versuche ohne die F dazwischen vom Strom zu nehmen
Einzelne Kabel ab, wieder ran. Mal sind die jew. LEDs der F dann sofort wieder dauerhaft an.
In anderen Versuchen (gleiches LAN ab und wieder ran, mehrfach probiert) blinkt die jew. LED der F, und zwar unterschiedlich oft bei der der selben L Buchse.
Bei L2 wenn ich mich nicht verzählt habe immer 6 mal, dann dauer-an.
Bei L1 + 4 mal öfter, mal seltener. Nach diversen Versuchen blieb dann W ganz aus und ging auch nicht wieder an. N hingegen ging immer, die F war also nicht komplett "aus" oder so.

3. Strom wieder weg, alle Kabel wieder ran. F an.
Dies auch mehrfach durchgeführt, mit jeweils anderen Ergebnissen:
- Mal sind alle LEDs an switch und die drei N,W,L an F sofort an und bleiben an.
- Dann wieder blinken sie alle gleichzeitig mehrfach und bleiben dann an.
- Dann wieder blinken sie ein oder zweimal gleichzeitig, dann fangen sie an in Gruppen an und aus zu gehen.
- Und dann bleiben sie halt alle an, oder einige.
- Zuletzt dreimal nacheinander "alle sofort und dauernd an".
Dauer der Stromlos-Phase länger/kürzer - kein Unterschied.
Verdacht: Spannungsversorgung "wackelt"!?

4. 12V 3(!)A Netzteil besorgt (statt dem 1.4A)
- Strom ran, weg, ran, weg, ran - immer alle 5 Ports am Switch sofort dauer-an, an der F nur N,W,L wie bisher.
- Nach ~ 1 min blinken alle LEDs am Switch und die drei an der F ein paar Mal synchron. Dann sind sie wieder alle dauer-an.
- DANACH ist das Verhalten wieder wie bei 2.: L1/2/4 mal weg, wieder ran, entspr. LED an der F blinkt ein paar Mal.
- Dieses Verhalten ist reproduzierbar, wobei die Phase "alle dauer-an" einmal ~85s dauert, beim nächsten Starten dann nur ~20s.
- Diese "Dauer bis blinken" scheint wiederum davon abzuhängen wie lange die F vorher stromlos war. Je länger stromlos, desto länger bis zum Blinken.
Seltsam. Irgendwas mit der internen Spannungsversorgung?

5. Aufgemacht, rein geschaut
- nichts offensichtliches (keine geplatzten SMD-Elkos, die drei großen sehen auch gut aus, keine Wölbung, nichts)
- Strom ran, hier und da gemessen, ich finde 12V an div. Stellen, sowie 1,3V / 3,3V / 5V hinter den scheinbar dafür jew. zuständigen "Regeler-Gruppen" (bin kein E-Techniker...)

=> Vielleicht ist die interne Spannungsversorgung aber hin ... oder halt irgend ein wesentliches Teilchen. Nur man sieht halt nix, und da bin ich am Ende.

Spoiler: YourFritz Ergebnisse

Kurz gesagt: NIX. Egal welcher LAN oder WAN-Port. Strom ran, LEDs an Switch und Fritte (sofern zugeordnet) an, steady. eva_discover los gejagt, gewartet, nicht gefunden. Aber bei jedem "BLIP" von eva_discover blinkt brav die jew. LED an Switch und Fritte.
Wireshark mitlaufen lassen. Sieht nur die ausgehenden UDP Pakete von eva_discover. Sonst nix.

TOT. Es sei denn, einer kann hellsehen und weiß, welches SMD-Atömchen da hopps sein soll. Aber ich glaube das war alles für'n A....

Naja, Spass gehabt, YourFritz kennen gelernt...
n8.

 

[NDiIPP]

Will wissen: ist einer davon mit einem "langen Pröppel" nur gesteckt, und der andere ohne "Pröppel" geklebt wie so ein "Möbel-Nupsi" vom schwedischen Möbelhaus?

Nein.

 

[PeterPawn]

Strom ran, LEDs an Switch und Fritte (sofern zugeordnet) an, steady. eva_discover los gejagt, gewartet, nicht gefunden.

Hier habe ich ein Problem beim Verständnis. Das lese ich so, als hättest Du erst die Box an den Strom gesteckt und dann "eva_discover" gestartet? Das wäre die falsche Reihenfolge ... die Box reagiert nur eine sehr begrenzte Zeit auf die Annäherungsversuche eines LAN-Clients (EVA is a little bit shy.) und es ist günstiger, wenn das Discovery-Skript schon sucht (deshalb auch das Ein-Sekunden-Intervall zwischen den Paketen), wenn die Box ihren Strom kriegt.

Ansonsten hört sich alles gut an oder eben auch nicht ... bei den LEDs bin ich dann irgendwann doch ausgestiegen. Wenn ich's richtig verstanden habe und richtig zusammenfasse, sind die Ethernet-Ports der Box alle elektrisch in Ordnung und die "auto negotiation" auf die 100 MBit/s (GbE ist ja beim verwendeten Switch nicht) klappt auch (so daß es wohl auch nicht daran scheitert, wenn keine Ethernet-Pakete zurückkommen).

Wenn die Environment-Files alle dieselben Werte bei "firmware_info" enthalten, dann ist da nie eine andere Firmware als 06.83 erfolgreich auf der Box gestartet oder danach funktionierte dann auch kein Zugriff per EVA mehr (womit keine weiteren Environment-Dateien erzeugt wurden).

Ansonsten sieht das Environment normal aus ... wenigstens hast Du uns hier jetzt die Gewißheit gebraucht (für mich war das neu), daß auch bei der 4040 die Seriennummer im Environment steht (das ist längst nicht bei allen Modellen so) und damit wohl ebenfalls nicht richtig "maskiert" wird bei der Datensammlung durch AVM.

Was mich halt irritiert ... wenn Du vier Environment-Files hast (und die alle vom Vortag sind), hat das Recovery-Programm ja auch bei vier Versuchen diese Daten auslesen können (ist das übliche Prinzip - jeder nur ein Kreuz und jeder Aufruf nur eine Environment-Datei).

Das würde ja bedeuten, daß es eben nicht direkt beim ersten Versuch mit dem Recovery-Programm die Späne gab (wo das wohl hängengeblieben war und Du zwei Stunden gewartet hast - wenn das nicht nur Deine Umschreibung für "eine lange Zeit" ist) und es danach zunächst mal noch möglich war, zumindest auf EVA zuzugreifen und das Environment auszulesen.

Irgendwie klingt das komisch ... ich kann der Beschreibung in #1 nur einen einzigen erfolgreichen Zugriff mit dem Recovery-Programm entnehmen.

Kläre mal zunächst, ob die Reihenfolge bei "Discovery" nur falsch beschrieben war oder ob Du das tatsächlich in der falschen Folge abgearbeitet hast. Einiges von dem, was Du bei den LED-Tests beschrieben hast, klingt für mich fast wieder so, als würde die Box doch irgendetwas starten. Also ist es nicht wirklich sinnvoll, da beim nächsten Mal (die Zeit der Tests der Elektrik der Ports wäre für mich vorbei) mehr als ein Kabel zwischen Switch und Box zu haben - ich würde die Box an LAN4 verbinden, damit die WLAN-LED davon nicht "überdeckt" wird. Normal ist es, wenn beim Start der Box erst mal alle LEDs kurz aufblinken (das dürfte bei den Dakota-Boxen dasselbe sein, wobei man das auch bei einer 7520 oder 7530 gegenchecken könnte), wenn die GPIO-Ports initialisiert werden - auch das wird bei den IPQ-Modellen nicht anders sein.

Danach sollte eigentlich Power einige Male vor sich hinblinken und genau in dieser Zeit ist üblicherweise auch der Kontakt zu EVA möglich. Jetzt spiele ich mal den Advocatus Diaboli und unterstelle, daß die Power-LED auch einfach defekt sein könnte ... die Info-LED bräucht erst mal einen passenden Grund, um sich zu zeigen. Außer am Beginn, da sollte sie eigentlich auch mit aufleuchten, wenn alle gleichzeitig initialisiert werden - nur würde das für die Power-LED eigentlich auch gelten. Ich werde also auch nicht ganz schlau daraus, was

P+I bleiben die ganze Zeit aus

heißt ... der Beschreibung darüber zufolge, zucken die auch beim Power-On nicht im geringsten und dann könnte auch die Info-LED ein Problem haben. Es wäre wichtig zu wissen, wie sich andere 4040 da verhalten, denn meine Behauptungen basieren auf dem Verhalten anderer Boxen, die nicht auf den Dakota-SoCs aufbauen.

Ich würde auch noch mal die Box ohne alle LAN-Kabel starten und sie einmal beim Power-On kurz filmen ... irgendein Smartphone für ein kurzes Video (ca. 10 Sekunden ab Power-On) hast Du sicherlich. Das gibt einen klareren Eindruck, als jede Beschreibung im Text und andere könnten das mit ihrer Box vergleichen und sich dann vielleicht eher zu einer Info "breitschlagen" lassen.

Danach dann noch einmal den Versuch, mit gestartetem "eva_discover" die Box mit Strom zu versorgen, während sie mit LAN4 am Switch hängt - auch das könnte man filmen. Vor allem würde mich an dieser Stelle interessieren, ob es nach der Wartezeit im Loader beim Power-On noch irgendeinen erkennbaren Status-Wechsel gibt, wenn die Box vielleicht doch noch ein System laden sollte oder es zumindest versucht.

Auch eine serielle Konsole wäre sicherlich nicht verkehrt ... vielleicht hast Du da ja was in der Bastelkiste. Irgendwo findet sich bestimmt auch ein Bild der Platine und ggf. sogar eine Beschreibung, wo die Kontakte sitzen. Erst wenn da auch nichts mehr zuckt, würde ich aufgeben ... wenn die Änderungen der LED-Anzeigen nicht rein elektrisch verursacht werden, müßte ja irgendeine Software die GPIO-Pins entsprechend umschalten.

Wobei es auch noch eine Möglichkeit gäbe, daß die FRITZ!Box mit der "auto negotiation" doch nicht so ganz 100% klarkommt ... ab und an kann es auch mal Sinn machen, wenn man da den kleinsten gemeinsamen Nenner (das wären 10 MBit/s, half-duplex) probiert - nur braucht man dafür dann einen Switch, bei dem man das passend einstellen kann, daß der nichts besseres zuläßt.

 

[elfri]

N'abend

eva_discover: sorry, schlampig getippt. Natürlich immer zuerst gestartet, ein paar "Pünktchen" gewartet, dann Power auf die Fritte.
Heute nochmal mit der guten 7490 verifiziert: Mein "detect.sh" funktioniert einwandfrei, die 7490 wird sofort gefunden. Laptop ist also "scharf".

Firmware-Historie: Kann ich nicht sagen. Weiß nicht, welche drauf war als ich sie bekam. Aber: mein erster Versuch mit der 7.14 ist ja schon beim MTD1 löschen gescheitert. Meine das habe ich 2x versucht. Beide Male blieb er nach MTD-1 löschen hängen. Die 2 Stunden kommen beim ersten Versuch durchaus gut hin... Abendessen und so Dann habe ich ein 3. Mal mit starkem Netzteil der 7490 versucht und das 7.14 lief ja laut Recov-Tool auch "angeblich" durch. Aber dann ging sie wie gesagt aus und das war's. Genau kriege ich das nicht mehr hin. Nicht gefilmt... wer rechnet auch damit. Was der 4. Versuch war erinnere ich nicht mehr. Jedenfalls, ja, das Recov 7.14 hat sie mehrfach gefunden. Eben bis MTD-1, und einmal "voll" durchgelaufen.

LEDs.
Vorweg: Alle LEDs leben, siehe weiter unten.

Erstmal zu dem was "normal" wäre. Ist hier nicht mehr. Wie gesagt, ich erinnere, dass sie beim ersten Test vor dem Kauf und dann auch daheim "relativ normal" daher blinkte - wie du beschreibst. Alle an-aus, dann Power usw. Habe ja keine "gesunde", und auch kein Video von dem, was ich sah.
ABER JETZT geht - wenn kein LAN-Kabel dran ist - keine einzige LED an, auch nicht für ein "Zucken" wenn sie Strom bekommt. Absolute dauerhafte Dunkelheit. Sobald ein LAN-Kabel kommt, gibt's Licht.

Also, Tests oben haben gezeigt:
- Fritte mit Switch(!, merken, siehe unten!) verbinden. => Je nach Port an der Fritte gehen NUR die LEDs für Wlan(=Port1), Internet(=2), Lan(=4).

Check ob Power & Info durchgeschmort sein können:
- Fritte an, Switch an Port1, Spannung an leuchtender WLan-LED gemessen: 2V.
- Bei allen LEDs liegt der rechte Kontakt (wenn man von vorn schaut) dauerhaft auf 3,3V.
- Wenn sie AUS sind, liegt der Linke auf 2,7V, es fallen also 0,5V über der LED ab.
- Wenn sie AN sollen wird der linke Kontakt auf 1,3V gezogen => Delta 2V => LED an.
- Also gemessen was an Info und Power los ist. Dauernd 2,7, egal wo ich ein Kabel anschließe.
- Wenn sie an sein hätten sollen hätte da irgendwann mal 1,3 anliegen müssen. War nicht zu erzeugen.
=> Annahme: LEDs sind okay, sie will sie nur nicht leuchten lassen.

Macht der Switch überhaupt noch was als "Switch" oder "Hub"?
Also eine Kaskade gebaut:

1) ohne 4040, "Basis-Zustand" bestätigen:
Fritz7490 => 100MBit Switch => Laptop (ohne 4040) => sehen, dass er eine IP zieht. Macht er wie erwartet.

2) mit 4040:
Fritz7490 => 100MBit Switch => Fritte Lan4 (LAN-LED an+blinkt) | Fritte Lan1 => Laptop
Und "Energie, Nummer 1".....und ---- whaaaat?
INFO-LED blinkt mehrfach rot mit pausen. Dann geht WLAN an, blinkt ein paar mal, dann mal "länger an", dann wieder aus, dann geht INFO wieder mal rot blinken, dann ist WLAN wieder dran... Eine IP bekommt der Laptop aber nicht mehr.
Erkenntnisse:
- 1: INFO LED rot ist nicht tot.
- 2: Irgendwas ist noch los in der Fritte.
- 3: Welche LED an geht scheint davon abhängig, was für ein Gerät am Port hängt. Mit 100MBit-Switch an Lan1-4/Wan der Fritte war weder Power noch Internet zum leuchten zu bringen. Mit einem ollen Laptop dann doch???

3) Switch + Laptop von Fritte getrennt. => Alle LEDs aus.
Dann Laptop wieder an Lan1 der Fritte. INFO blinkt unregelmäßig rot. Dann WLAN. Wie bei 2. INFO / WLAN jew. mehrfach und jew. unregelmäßig im wechsel.

4) alle wieder ab (="awa"). Laptop an L2 der F. Switch weg gelassen. Keine Reaktion, alles dunkel.

5) awa. Laptop an L3, kein Switch. POWER blinkt 6 Mal, bleibt dann aus. Fast reproduzierbar. Lap wieder weg, kurz warten, Lap wieder ran. Diesmal blinkt POWER immer kurz-kurz...pause...kurz-kurz... usw, 7 mal. Dann wieder aus.

6) awa. Laptop an L4, kein Switch. INFO GRÜN blinkt mehrfach kurz-kurz-pause...dann übergibt sie an LAN. Die bleibt dann länger an, blinkt ab und an mal.

7) awa. Laptop an WAN, kein Switch. Keine Reaktion, alles dunkel.

8) awa. Switch an WAN. Keine Reaktion. Laptop dazu an L4. Gleiches wie bei 6), erst INFO, dann LAN blinkblink.

Gelernt? Fritte kann in dieser Kombi keinen Uplink zum Switch durchstellen. Aber die LEDs leben alle!

9) awa. Switch raus, nur 7490 <> WAN-Fritte; Keine Reaktion.
Zusätzlich Laptop an Fritte-L4 => LAN-LED blinkt direkt (nicht erst "INFO" wie bei 6 wenn kein Kabel an "WAN" steckt). Reproduzierbar.

10) awa. 7490 an L1. INFO blinkt mehrfach rot, dann übernimmt WLAN.
Laptop dazu an L4. INFO blinkt mehrfach grün, dann übernimmt LAN.
WLAN (L1, wo die 7490 hängt) blinkt munter weiter.
Eine IP bekommt der Laptop von der 7490 aber nicht...

11) Strom von der Fritte weg. Laptop an L4 gelassen.
eva_discover meckert weil noch kein Media Sensing, lässt sich also nicht unmittelbar starten. Annahme, dass wenn die Fritte irgendwie reagiert sie das nicht nur in Sekunde 0-2 macht.
Also los:
Strom an die Fritte, und sofort eva_discover losgejagt... Punkte, Punkte.... aber keine Fritte gefunden.
Im Wireshark Log sehe ich auch nichts zurück kommen.

Tja.... ich denk mal, wenn, dann ist es Zeit für GPIO / Console Spielchen. Noch nie gemacht. 3,3V auf der Fritte, das geht ja nicht direkt an einen RS-232 <> USB-Konverter (den hab ich.) Ansonsten habe ich nur einen CubieTruck rumliegen, der hat auch GPIO-Pins, aber die sind nicht identisch mit denen vom Raspi. Da muss ich wohl erst mal tief "wühlen" wie ich da eine Konsole hin biege.... morgen oder so.

Gute n8.

Anbei Bilder der Platine.
Oben:

Unten:

 

[H´Sishi]

Es gibt USB <-> RS232-Adapter, die RS232-seitig mit 3,3V-Pegel arbeiten.

Hmm, irgendwie sieht die Unterseite aus, als ob da was fehlt:
Rechts unterhalb vom untersten LAN-Port ist ein Bereich für einen SMD-IC, dessen Kontakt- bzw. Lötflächen ungleichmäßig mit Lötzinn benetzt sind. Das macht auf mich den Eindruck, daß da was ausgelötet wurde ... ich bin mir da nicht mal sicher, ob die Lötflächen nicht sogar irgendwo einen Kurzschluss haben.

 

[elfri]

So einen Adapter wollte ich wenn möglich nicht erst besorgen. Ich glaube die GPIO meines cubietruck stellen auch einen 3,3V Port direkt bereit. Eigentlich müsste ich dann direkt GND, Rx/Tx und Tx/Rx verbinden können (aber nicht die 3,3V selbst). Haben wohl zumindest andere mit raspi und anderen Routern schon gemacht.

Ausgelötet...ja das dachte ich auch erst, ist aber wohl normal so. Vergleichsbild hier:

AVM FRITZ!Box 4040

AVM FRITZ!Box 4040 AVM FRITZ!Box 4040 is a versatile home router, supporting 802.11ac Wi-Fi and Gigabit Ethernet but has no integrated modem. Instead, the WAN port can be connected to several types of upstream modems like fiber, cable or DSL. Sourcecode:

openwrt.org

Also werde das mit der ser.cons mal verfolgen. Bei Gelegenheit...

 

[H´Sishi]

Ok, dann ist das mit dem ausgelöteten Chip falscher Alarm . Aber trotzdem komisch, das sieht aus, als ob in einer leicht anderen Hardware-Konfiguration da was verbaut ist.

Was die RS232-Selbstbau-Verbindung angeht - denk' an die Verkreuzung von RxD und TxD - der RxD des einen ist der TxD des anderen .

 

[Joe_57]

der RxD des einen ist der TxD des anderen

Genau so hab ich das mal vor vielen Jahren als korrekte Verkabelung einer seriellen Schnittstelle gelernt.
Ist das zwischenzeitlich geändert worden?

 

[H´Sishi]

Nein, ist immer noch so bei RS232.
Aktuelle LAN-Ports beherrschen seit 1GBit-Einführung die Auto-Aushandlung. Da kann man 1:1- und CrossOver-Kabel nach Belieben anstöpseln.

 

[elfri]

Nur falls das einer liest der nicht so Firm ist (wie ich): Meines Wissens nach ist "TTL" (Transistor to Transistor Logic) absolut nicht das selbe wie "RS232" - letzteres ist soweit ich weiß das, was man gemeinhin früher unter "serielle Schnittstelle" am PC hatte... wo dann gern mal 5V oder mehr drauf sind. Die TTLs die wir hier vor uns haben (in der Fritte, oder auch auf einem Cubietruck) vertragen aber nur 3,3V Signalpegel. Wenn man da jetzt einfach "RS232" zu sagt und einer dann TX/RX aus seinem guten alten "Seriellen Port" drauf haut - brutzel... das war's dann mit der Fritte oder einem Cubietruck.

Letzterer hat einen "fertigen" UART-Connector mit 3,3V, der wohl ttyS1 sein müsste. Der würde theoretisch also direkt mit dem der Fritte (natürlich "gekreuzt") harmonieren. Aber da ich noch nicht ganz sicher bin mache ich mich da erstmal noch weiter schlau. Dieser UART wird nämlich fast immer nur in Verbindung mit einem "TTL to USB"-Kabel erwähnt. Das verwirrt mich. Ich will ja TTL to TTL machen.

Also, vielleicht werfe ich hier was durcheinander... aber besser selbst schlau machen, ich kann falsch liegen (aber dann besser nichts gemacht zu haben, als das was "schmort").

Bin mal weiter suchen

 

[H´Sishi]

Stimmt, TTL-Logic arbeitet mit 5V Signalpegel-Spannung.

Wie gesagt, es gibt USB <-> RS232-Adapter mit 3,3V Signalpegel; die meisten dürften allerdings mit 5V oder sogar mehr daherkommen. Daher mein Hinweis in #8.

 

[stoney]

FTDI232 zb von AZ-Delivery ist ein häufig erwähntes/r Produkt/Chip.
Hab mir selbst mal angeschafft für die F!Ben.

 

[Grisu_]

Na daß ihr euch da nicht mal täuscht!

RS232 hatte seit jeher +/-15V, also >+3V für logische 0 und <-3V für logische 0, zw. -3V und +3V ist kein Zustand definiert, siehe auch hier: https://www.mikrocontroller.net/articles/RS-232
Nur am PC (original wurden noch die +/-12V verwendet) wurden dann die Spannungspegel wegen USB mit nur +5V nach unten verbogen und negative zudem auch noch ignoriert.
Das Protokoll blieb gleich, aber mit den Spannungen hat man halt getrickst.
Mit 2 Dioden sollten die Pegel auch anpaßbar sein, einfach eine 3,3V Zener auf Rx und Tx gegen Masse sollte eigentl. genügen ohne jetzt lang nachdenken zu wollen.
Update: 2 Widerstände sind laut dem Artikel sogar geeigneter, die Geräte/Chips haben sowieso an den Eingängen Überspannungsdioden verbaut!

 

[H´Sishi]

Ach guck, sogar mit 15 V ... ich hatte zunächst an 12V maximal gedacht, aber habe gerade nicht die Zeit das nachzuschlagen.
Wieder was gelernt .

Der AZ-Delivery-Adapter ist schick.

 

[elfri]

Stimmt, TTL-Logic arbeitet mit 5V Signalpegel-Spannung.

Wie gesagt, es gibt USB <-> RS232-Adapter mit 3,3V Signalpegel; die meisten dürften allerdings mit 5V oder sogar mehr daherkommen. Daher mein Hinweis in #8.

Jetzt bin ich verwirrt. Ich denke:
- USB = 5V
- Damit: "normale" USB-Ser-Adapter =5V.
- Also aufpassen wenn man für seinen "normalen" Rechner mit nur noch USB einen USB - Ser Adapter besorgt, der dann auch nur 5V kann.
- Also einen Adapter besorgen der 3,3V aus den 5V vom USB macht.
- denn: viele TTL Ports auf den div. Einplatinenkomputerchen machen nur 3,3V (und nicht wie man aus der Aussage von H'Sishi oben folgern könnte 5V).

 

[H´Sishi]

(OffTopic)

Ok, zum Verständnis:

USB:
Die Standard-USB-Versorgungsspannung liegt bei 5V. Ein USB2-Port z.B. kann dabei maximal 500 mA abgeben, um angeschlossene Geräte wie einen Adapter zu versorgen. Neuere USB-Standards erlauben höhere Spannungen und Ströme.
Die Signalübertragung läuft bidirektional in Datenpaketen über zwei Adern "D+" und "D-". Das funktioniert auch ohne Spannungsversorgung, wenn das angeschlossene Gerät eine eigene Spannungsversorgung besitzt.
Da an einem PC-USB-Port mittels USB-Hub mehrere Geräte verbunden sein können, beinhalten die Datenpakete unter anderem auch eine Geräteadresse.

RS232:
An RS232-Verbindungen gibt es keine Spannungsversorgung für das angeschlossene Gerät, allerdings einen "Ground"-Pin, gegen den die Signalpegel an den Sende-, Empfangs- und ggfs. Steuersignalen gemessen werden.
Die Signalübertragung läuft getrennt über separate Adern "TxD" (Senderichtung) und "RxD" (Empfangsrichtung).
Die Signalpegel können, je nach Ausführung, bis zu 15V betragen. Dabei bedeuten Potentialunterschiede über 3V "1", unter 3V "0".

Adapter, von denen wir hier reden, setzen die USB-Datenpakete (welche neben den Nutzdaten Geräte-Adressen und andere Protokollinformationen beinhalten) in das RS232-Signal um und umgekehrt. Dabei werden die RS232-Signale von dem Adapterchip erzeugt und im Fall des oben genannten Adapters auf 5V oder 3,3V (je nach Jumper-Stellung) begrenzt.
Ich habe auf Amazon einen "DSD TECH SH-U09C5" gefunden, der 5V, 3,3V, 2,5V und 1,8V Signalpegel kann. Die gewünschte Pegelspannung wird auch hier per Jumper gesetzt.

Theoretisch könnten die Einplatinenkomputerchen an ihren RS232-Schnittstellen auch Signale mit 5V ("echtes" TTL) oder 15V Signalpegel liefern. Allerdings sind dafür zusätzliche Bauteile (Spannungswandler, Schutz- und andere passive Bauteile) sowie die eigentliche Schnittstelle notwendig, die sich dann wegen der für die übrigen Computer-Teile gefährlichen Spannung in einem abgegrenzten Bereich befinden müssen.
Das bedeutet Mehraufwand im Design und zusätzliche Bauteil- und Fertigungskosten. Also behilft man sich mit 3,3V-Schnittstellen, die dann beliebig platziert werden können und für die es preisgünstige Adapter inklusive passender Verbindungskabel gibt.

Bei meinem "anschlußfertigen" USB2-RS232-Adapter befindet sich die Elektronik im 9-poligen RS232-Stecker. Den kann ich allerdings nicht umstellen auf andere Pegelspannungen als 3,3V.

 

[Grisu_]

Ein "richtiger" RS232-USB Adapter macht daraus selbst die +/-15V wenn etwa der teure MAX232 verbaut ist. Siehe hier: http://www.elektronik-magazin.de/page/der-pegelumsetzer-max232-15
Die meisten günstigeren verzichten darauf und die Eingänge sind da relativ großzügig, und interpretieren einfach alles unter 2V als 1 und darüber als 0.
Auch TTL ist heutzutage nicht mehr ganz wie es in Ursprungszeiten exakt definiert war, kann man auch Fortschritt nennen.

Serielle Schnittstelle am PC (gibts heut ja kaum mehr) hat übrigens richtige Signalpegel, da im PC ohnedies die +/-12V vorhanden sind und dafür genutzt werden.
+/-15V sind ja nicht erforderlich, es heißt ja nur, daß am Eingang +/-3V ankommen müssen, je länger das Kabel desto länger eben die dafür nötige Spannung am Ausgang bis zu max. +/-15V.
Somit sind die +5V vom USB auch für kurze Strecken vollkommend ausreichend, es muß nur der Eingang geschützt werden damit mögliche 15V keinen Schaden verursachen.
Das Problem ist jedoch, daß USB keine negativen Spannungen kenn die erforderlich wären, daher mogelt man und erlaubt alles unter 2V bereits als logische 1.

@H'Sishi: Stimmt nicht, richtiger RS232 interpretiert alles <-3V als 1, nicht wie du schreibst unter +3V, zw. -3 und 3V ist keine definierter Zustand!
Hier noch etwas Lesestoff aus dem Arduino Forum, hab aber nicht geguckt ob alles korrekt darin ist, großteils dürften die Aussagen aber stimmen was ich so überflogen hab. https://forum.arduino.cc/index.php?topic=496799.0