Ethernet-Karte Hänger

[ProgBernie]

Neue Erkenntnisse: Die Karte lässt sich reproduzierbar in den Zustand verbringen. Sie beantwortet testweise gesendete ICMP-Echo-Requests mit einer Payload bis zu 1468 Bytes, entsprechend 1510 Bytes Framelänge (plus 4 Byte FCS), zuverlässig, die ICMP-Echo-Replies haben dann eine Framelänge von 1514 Bytes.
Ab 1469 bis zu 1472 Bytes Payload (1511..1514 Bytes Frame plus 4 Byte FCS) werden Requests nicht mehr beantwortet und die Karte hängt sich manchmal auf (bei 1472 Bytes sehr oft).
Ab 1473 Bytes Payload entsprechend 2 Frames (Fragmented IP Protocol, 2 Frames mit 1514 und 35 Bytes da die MTU beim verwendeten Rechner auf 1500 steht) geht die Karte reproduzierbar in den Hänger mit der Anzeige "RAM-Fehler" über.

Damit wird auch klar, warum das Problem nicht ohne Traffic und bisher auch nicht bei nur internem Traffic im LAN auftritt: Es sendet intern keiner fragmentiert. Das kommt von außen (dann auf den Port 134). Dummerweise kann ich das aktuell nicht ohne weiteres unterbinden.

Ich habe mal den Wireshark-Trace mit den gefilterten Paketen angehängt, ein Dauerping mit Standard-Nutzdaten, einer mit dem Ping of death. Man sieht daß die Karte sogar noch Pings nach dem Todespaket beantwortet bevor sie stirbt:

itelex-kill-filtered.pcapng.zip

[detlef]

Das sieht nach einem Pufferüberlauf aus.

[FredSonnenrein]

Danke für deine Mühen. Mit dem Dateianhang kann ich mangels Kenntnissen nichts anfangen. Aber mich interessiert sehr, warum dann ein RAM-Fehler angezeigt wird, ich vermute auch dass es kein RAM-Fehler ist, sondern das initialisieren des ENC28J60 schiefgeht.
Kannst du bitte mal den genauen Ablauf der LED der Ethernet-Karte nach dem Ping of death beschreiben?

[ProgBernie]

Ich vermute eher daß da arbiträr irgendwas direkt über den Stack angesprungen wird.
Ein schlechtes Video sagt mehr als eine gute Beschreibung:

20200701_112136.mp4

Sorry für die Schaukelei, in Seesternchenposition die rechte Hand mit dem Handy vors Rack halten und mit der linken ganz unten den Laptop bedienen...

[FredSonnenrein]

In der Tat merkwürdig, ein Reset nach Timeout käme entweder später und müsste mit blauer LED beginnen.

[ProgBernie]

Update: Auch mit Firmware 875 keine Besserung.

[FredSonnenrein]

An den Ethernet / TCP-Stacks ist auch seit Beginn der Entwicklung fast nichts geändert worden. Leider ist das "Basisprojekt" OpenMCP vor etlichen Jahren "abgestorben". Daher werden neue Versionen keine Besserungen in deinem Problem bringen können.

Fangen wir mal weiter oben an... Was für eine Stromversorgung hast du? Kann es sein, dass die unter Umständen einknickt und Störungen verursacht?

Oder ein ganz anderer Ansatz: Nimm mal alles in deinem Heimnetz außer Betrieb, was nicht i-Telex ist. Kommen die Abstürze dann auch noch?

[BjoernS]

(Nebenbei: Scheinbar hat der ursprüngliche Entwickler vor einem Jahr den letzten Stand von OpenMCP auf Github hochgeladen, unter GPL 2.0. Mit entsprechenden Kenntnissen der Architektur wäre ein Fork für i-Telex machbar.)

[FredSonnenrein]

Ui, das ist interessant, da werde ich mich mal einklinken.

[ProgBernie]

So, ich habe jetzt 2 Änderungen getestet:

1. Für die ICMP-Antwort wird der ursprünglich empfangene Frame modifiziert und wieder zum Versand gegeben. Dabei wurde übersehen, daß der Empfangsframe die Prüfsumme am Ende enthält, diese beim Senden aber vom Chip selber angehängt wird (Register MACON3 Bits PADCFG). Dadurch wurde der ICMP-Reply um 4 Bytes zu lang gesendet. Lustigerweise steht sogar an der Stelle im code der Kommentar "length - 4", aber der code zieht da keine 4 ab...
Mit der Änderung können nun ICMP-ECHO-Requests mit bis zu 1472 Byte Länge korrekt verarbeitet werden (bisher: 1468)
ICMP-Echo-requests mit 1473 Bytes Payload bringen die Karte weiterhin in den Orkus...

2. Soweit ich sehen kann werden fragmentierte Pakete mit mehreren Frames nicht in der Ethernet-Schicht gehandhabt, sondern müssten in tieferliegenden Schichten behandelt werden. Zumindest die Schichten IP und ICMP tun das nicht. Damit würde ein zu langer ICMP-Echo-request in 2 Frames eintrudeln, wobei nur der erste einen IP-Header hat und das zweite Fragment erst angehängt werden müsste, bevor es in der IP-Schicht weiterverarbeitet wird. Da beim ersten Fragment der IP-Header und der ICMP-Header korrekt sind, müsste das hier trotzdem funktionieren, der Reply hätte dann eine zu geringe Länge. Der zweite Frame würde irgendwelchen Unsinn enthalten und vermutlich sofort verworfen werden. Dennoch habe ich testweise eingebaut, daß Frames mit Fragmenten gleich verworfen werden (auch dies war in Kommentaren bereits vorgesehen).
Dennoch bringt ein ICMP-ECHO-Request mit mehreren Frames die Karte gleich wieder in den Abgrund.

Meine Überlegung geht jetzt noch in eine andere Richtung: Soweit ich sehe wird die Ethernet-Routine im Interrupt aufgerufen. Fragentierte Pakete werden aber vermutlich so schnell wie möglich nacheinander gesendet, möglicherweise back-to-back, lediglich durch Präambel und SFD getrennt. Damit könnte während der Interruptbearbeitung ein weiterer vom ENC28J60 generiert werden, zumal das zweite Fragment beliebig kurz sein kann. Keine Ahnung wie das gehandhabt wird und was da passieren kann.
Also Test: Floodping an die Karte senden. Mit der Defaultlänge funktioniert das relativ gut, bei größeren Längen rebootet die Karte schnell (allerdings ohne den Hänger). Scheint also nicht so ganz sauber zu laufen, packet loss wäre OK, reboot nicht.

Ein kurzer Vergleich von OpenMCP auf github zeigt zumindest an den beiden ersten Stellen keinen Unterschied, also zumindest der ICMP-Bug ist da ebenfalls drin. Ich sehe, es ist noch mehr zu tun...