Verbindungsprobleme mit PL4

[vfitzek]

Kann das sein das der WLAN-Chip da Blödsinn treibt? Ich hab mir das mal Angeschaut.
Wenn ich z.B. ein Backup vom PL4 ziehe, kommen immer schön 70Byte Pakete (16Byte Nutzdaten) zum GCC-Rechner und 68Bytes (14 Bytes Nutzdaten) zum PL4 zurück. Zwischendrin kommt aber nur ein 64er Paket vom PL4. Das wird dann als "Ethernet Frame Check Sequence Incorrect" als schlechtes Paket erkannt. Und diese Pakete kommen laufend. Meistens schickt er das korrekte Paket dann gleich hinterher. Wenn nicht? Connection Lost!

Niedlich wird's wenn man sich das Paket mal anschaut.
Schlechtes Paket:
...
0030 08 60 1f 51 00 00 00 00 00 00 00 00 00 00 00 00

Gutes Paket:
...
0030 06 56 83 3f 00 00 01 70 51 c2 02 46 4c 41 40 30
0040 30 30 30 03 5c 04

Anstatt 16 Bytes Nutzdaten kommen 10 Bytes Nullen... (Edit: eigentlich darf da gar nix sein, da die Pakete ohne [PSH] eigentlich keine Nutzdaten haben sollten!)

Noch etwas:
Solange TCP-Flags [Push, Ack] gesetzt sind, ist alles gut. Alle Pakete [ACK] oder [RST, ACK] haben eine falsche "Frame Check Sequence" da sie alle mit den 10 Nullen aufhören. Kommen zwei dieser [ACK] Pakete hintereinander bricht die Verbindung ab.
GCC->PL4 [PSH, ACK]
PL4->GCC [PSH, ACK]
GCC->PL4 [ACK] bad frame
GCC->PL4 [PSH, ACK]
PL4->GCC [PSH, ACK]
GCC->PL4 [ACK] bad frame
Diesmal kommt das Paket nicht korrigiert
also: Wartezeit "Connection Timeout"
GCC->PL4 [FIN,ACK] (Verbindung beenden)
PL4->GCC [RST,ACK] bad frame
GCC->PL4 [SYN] (Neuaufbau der Verbindung)
PL4->GCC [SYN,ACK] bad frame
GCC->PL4 [ACK]
GCC->PL4 [PSH,ACK] (wenn dies nicht kommt = Kommunikationsfehler Error Code 28 und nix geht mehr)
…

Ein gutes [ACK] Paket hat üblicherweise 54Bytes, die bad frames haben 64Bytes.
gutes ACK:
0030 ff 70 82 69 00 00

Kann das sein, das da einfach die Schreibpufferlänge 10Bytes zu lang ist, und er deshalb an alles andere 10Bytes eines geleerten Puffers dranhängt? Er also alles unter 64Bytes mit Nullen auffüllt?


Also ein böses [ACK]Paket genommen, auf 54Bytes gestutzt und nochmal geprüft. Siehe da: Das Paket ist nun korrekt. Also wurde die Prüfsumme für das 54Byte Packet erstellt, und die Nullen haben da nix verloren!

Vielleicht hilts Euch ja weiter.

Schönen Gruss, Volker