TCP-Handshake unvollständig (ACK fehlt)

Nelson OP #7928770
Lesenswert?
• ▲
▼

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:

1
 
    prvIPTask started

2
 


3
 
    Starting network up.

4
 


5
 
    uart puts on core1 working

6
 
    printf on core1 working

7
 
    main_Core1 has started!

8
 
    Core1 starts Scheduler

9
 
    Network card successfully initialised.

10
 
    Waiting for ifup...

11
 
    network is up and running.

12
 
    Socket 10310 -> 0.0.0.0:0 State eCLOSED->eTCP_LISTEN

13
 
    Socket 10400 -> 0.0.0.0:0 State eCLOSED->eTCP_LISTEN

14
 
    Network buffers: 96 lowest 96

15
 
    Network buffers: 96 lowest 95

16
 
    Network buffers: 95 lowest 94

17
 
    Network buffers: 94 lowest 93

18
 
    Network buffers: 92 lowest 92

19
 
    Network buffers: 91 lowest 91

20
 
    Gain: Socket 10310 now has 1 / 20 child

21
 
    prvSocketSetMSS: 1460 bytes for 192.168.178.15:35657

22
 
    Socket 10310 -> 192.168.178.15:35657 State eCLOSED->eSYN_FIRST

23
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED

24
 
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

25
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEI

26
 
    Network buffers: 90 lowest 90

27
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED

28
 
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

29
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEIVED->eSYN_FIRST

30
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED

31
 
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

32
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEIVED->eSYN_FIRST

33
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED

34
 
    Network buffers: 91 lowest 89

35
 
    eSYN_RECEIVED: ACK expected, not SYN: peer missed our SYN+ACK

36
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_RECEIVED->eSYN_FIRST

37
 
    Socket 10310 -> 192.168.178.15:35657 State eSYN_FIRST->eSYN_RECEIVED

Hat Jemand einen Tipp, wo der Fehler liegt?

Angehängte Dateien:
: Bearbeitet durch User
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Nelson OP #7928786
Lesenswert?
• ▲
▼

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 ;)

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Cyblord -. #7928791
Lesenswert?
• ▲
▼

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.

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nelson OP #7928825
Lesenswert?
• ▲
▼

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:

1
 
#define ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM    ( 1 )

2
 
#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

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter S. #7928834
Lesenswert?
• ▲
▼

Nelson schrieb:

FreeRTOS hat dafür 2 Variablen:

1
 
> #define ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM    ( 1 )

2
 
> #define ipconfigDRIVER_INCLUDED_RX_IP_CHECKSUM    ( 1 )

3
 
>

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.

: Bearbeitet durch User
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nelson OP #7928843
Lesenswert?
• ▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren