TCP-Handshake unvollständig (ACK fehlt)

[Nelson (labnelson)]

Ich portiere gerade FreeRTOS-Plus-TCP (mit entsprechender Anwendung) auf 
den RaspberryPi4 und habe Probleme mich mit meinem dev-PC per TCP zu 
verbinden:
 1. system:
RPi4 mit ENC28J60 Netzwerk-Adapter (192.168.178.91)
Es läuft FreeRTOS (baremetal) mit Uart Debug Ausgabe

 2. system:
dev-pc mit Win11 (192.168.178.15)
Befehl per PowerShell: 'Test-NetConnection -ComputerName 192.168.178.91 
-Port 10310'

Beide System sind mit einem normalen Patch-Kabel verbunden (der dev-pc 
übernimmt MDIX, der ENC hat kein MDIX) [keine Switch, kein Router ist 
dazwischen]
Die Gateway-Einstellungen sind auf beiden System leer gelassen, nur die 
IP-Adresse und die Netzmaske: 255.255.255.0 sind ausgefüllt

**Mein Problem:**

Der dev-pc sendet ein SYN und der RPi4 antwortet mit SYN+ACK. Die 
ACK-Nachricht vom dev-pc fehlt, siehe Wireshark-Aufzeichnung.

Aufgrund dessen sendet der dev-pc das SYN-Packet wiederholt.

Die RPi4 debug Ausgabe zeigt die Antwort auf das SYN-paket mit dem 
SYN+ACK Packet:

    prvIPTask started

    Starting network up.

    uart puts on core1 working
    printf on core1 working
    main_Core1 has started!
    Core1 starts Scheduler
    Network card successfully initialised.
    Waiting for ifup...
    network is up and running.
    Socket 10310 -> 0.0.0.0:0 State eCLOSED->eTCP_LISTEN
    Socket 10400 -> 0.0.0.0:0 State eCLOSED->eTCP_LISTEN
    Network buffers: 96 lowest 96
    Network buffers: 96 lowest 95
    Network buffers: 95 lowest 94
    Network buffers: 94 lowest 93
    Network buffers: 92 lowest 92
    Network buffers: 91 lowest 91
    Gain: Socket 10310 now has 1 / 20 child
    prvSocketSetMSS: 1460 bytes for 192.168.178.15:35657
    Socket 10310 -> 192.168.178.15:35657 State eCLOSED->eSYN_FIRST
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEI
    Network buffers: 90 lowest 90
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEIVED->eSYN_FIRST
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEIVED->eSYN_FIRST
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED
    Network buffers: 91 lowest 89
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEIVED->eSYN_FIRST
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED

Hat Jemand einen Tipp, wo der Fehler liegt?

[Wastl (hartundweichware)]

Nelson schrieb:
> RPi4 mit ENC28J60 Netzwerk-Adapter (192.168.178.91)

Oh weh, die lahme alte Krücke (15-20 Jahre alt) zusammen mit
einem sehr modernen Mikrocontroller? Ich denke da gibt es
bessere Lösungen ....

Ja, ich weiss, bin etwas abseits des Topics.

[Nelson (labnelson)]

Wastl schrieb:
> Oh weh, die lahme alte Krücke (15-20 Jahre alt) zusammen mit
> einem sehr modernen Mikrocontroller? Ich denke da gibt es
> bessere Lösungen ....
>
> Ja, ich weiss, bin etwas abseits des Topics.

Das ist definitiv was dran. Leider habe ich es noch nicht hinbekommen 
einen C-Treiber (baremetal) für den onBoard Ethernet-Chip des RPi4 zu 
finden/schreiben. In meiner Anwendung geht es nicht um hohe Bandbreite.
Ich portiere CAMeL-View (https://camelview.org/) auf den RPi4.
Wenn du dafür eine Lösung hast, auch gerne ;)

[Cyblord -. (cyblord)]

Wastl schrieb:
> Oh weh, die lahme alte Krücke (15-20 Jahre alt) zusammen mit
> einem sehr modernen Mikrocontroller? Ich denke da gibt es
> bessere Lösungen ....

Stimmt aber der ENC funktioniert. Wenn dann liegt es an der SW die ja 
den ganzen TCP/IP Stack komplett selbst implementieren muss. Aber sogar 
das habe ich schon auf einem ATmega ohne Probleme gemacht. Ein RPI4 ist 
da Luxus.

[Wastl (hartundweichware)]

Nelson schrieb:
> Wenn du dafür eine Lösung hast, auch gerne ;)

Schön dass du das einsiehst. Gleich werden hier wieder Leute
auftreten die kein Gefallen an meiner Meckerei an dem "uralten"
Ethernet Chip finden.

Wenn du keine sehr speziellen Ansprüche an TCP oder UDP hast
dann bietet sich der W5500 an. Erspart einem sehr viel Arbeit
im Low-Level.

[Wastl (hartundweichware)]

Cyblord -. schrieb:
> Stimmt aber der ENC funktioniert.

Ich habe nicht behauptet dass er nicht funktioniert.

[Harald K. (kirnbichler)]

Nelson schrieb:
> RPi4 mit ENC28J60

Soll das ein zusätzliches Netzwerkinterface sein, oder warum tust Du Dir 
das an? Im RPi 4 ist ja schon eines eingebaut ...

[Wastl (hartundweichware)]

Harald K. schrieb:
> Im RPi 4 ist ja schon eines eingebaut ...

Kenne mich ja bei den Raspberries nicht aus, aber möglicherweise
würde es reichen einen externen PHY anzuschliessen. Auch dazu
gibt es fast fertige Lösungen. Siehe DP83848, LAN8720 etc.

Kriegt man fast geschenkt:

https://www.ebay.de/itm/286436358374

[Wastl (hartundweichware)]

Wastl schrieb:
> Kenne mich ja bei den Raspberries nicht aus

Ach so, da steht es ja ....

Nelson schrieb:
> für den onBoard Ethernet-Chip des RPi4

[Wastl (hartundweichware)]

Nelson schrieb:
> Ich portiere CAMeL-View (https://camelview.org/) auf den RPi4.

Nach meiner längeren Aufwachzeit am Morgen, mehrere Blicke
auf camelview, und die Bewertung der Registrierungsdaten des
TO, bleibt bei mir ein Verdacht auf einen Freitags-Tread.

YMMV

[Mario M. (thelonging)]

Schon mal die Windows-Firewall ausgeschaltet oder deren Logging 
eingeschaltet? Stell doch mal die pcap-Datei hier ein, dass man 
nachschauen kann, ob das SYN-ACK-Paket irgendwie "malformed" ist.

P.S. Was sagt netstat zu dem Socket?

[Nelson (labnelson)]

Wastl schrieb:
> Wenn du keine sehr speziellen Ansprüche an TCP oder UDP hast
> dann bietet sich der W5500 an. Erspart einem sehr viel Arbeit
> im Low-Level.

Danke für den Tipp, ich schaue bei Zeiten mal, ob es dafür C-Treiber 
gibt.
Den ENC habe ich genommen, weil ich direkt C-Treiber gefunden habe. Dann 
war das Problem schonmal weg (wenn auch nicht mit Top Performance).
Es geht erstmal darum, alles zum Laufen zu bringen und dann die 
Performance zu steigern.


Mario M. schrieb:
> Schon mal die Windows-Firewall ausgeschaltet oder deren Logging
> eingeschaltet? Stell doch mal die pcap-Datei hier ein, dass man
> nachschauen kann, ob das SYN-ACK-Paket irgendwie "malformed" ist.
>
> P.S. Was sagt netstat zu dem Socket?

Ich habe die Firewall ausgeschaltet, sämtliche offloads deaktiviert und 
die Ethernet-Schnittstelle zurückgesetzt.

Letztendlich habe ich mit dem Wireshark-Filter
tcp.analysis.flags
festgestellt, dass die Checksum des ACK nicht korrekt ist. FreeRTOS hat 
dafür 2 Variablen:

#define ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM    ( 1 )
#define ipconfigDRIVER_INCLUDED_RX_IP_CHECKSUM    ( 1 )

beide auf 0 gesetzt hat das Problem gelöst. Lange Suche, glückliche 
Lösung :)

Danke für eure Hilfe

[Cyblord -. (cyblord)]

Nelson schrieb:
> Danke für den Tipp, ich schaue bei Zeiten mal, ob es dafür C-Treiber
> gibt.

Es gibt C Treiber und ein socket interface. Aber so richtig 
Standardkonform ist das nicht.

[Dieter S. (ds1)]

Nelson schrieb:
> FreeRTOS hat dafür 2 Variablen:
>

> #define ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM    ( 1 )
> #define ipconfigDRIVER_INCLUDED_RX_IP_CHECKSUM    ( 1 )
>

> beide auf 0 gesetzt hat das Problem gelöst.

Es hängt vom verwendeten Treiber für die Ethernet Hardware ab wie man 
diese Flags in FreeRTOS setzen muss.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Nelson schrieb:
> festgestellt, dass die Checksum des ACK nicht korrekt ist.

Also die Header-Checksumme? So aus Neugier, hast du mal nachgeschaut 
wer/was die Header-Checksumme versaut? Schon FreeRTOS? Weil die 
Checksumme wird wenn nötig auch von dazwischen liegenden Netzwerkgeräten 
neu berechnet.

Die Berechnung selber ist ja nicht schwierig (RFC 791).

[Dieter S. (ds1)]

Die Thematik ist eigentlich uralt: "TCP Checksum Offloading". Man muss 
halt FreeRTOS auch korrekt sagen was der Treiber macht.

[Nelson (labnelson)]

Hannes J. schrieb:
> Nelson schrieb:
>> festgestellt, dass die Checksum des ACK nicht korrekt ist.
>
> Also die Header-Checksumme? So aus Neugier, hast du mal nachgeschaut
> wer/was die Header-Checksumme versaut? Schon FreeRTOS? Weil die
> Checksumme wird wenn nötig auch von dazwischen liegenden Netzwerkgeräten
> neu berechnet.
>
> Die Berechnung selber ist ja nicht schwierig (RFC 791).

Die TCP Checksumme war nicht korrekt.