TCPIP Kommunikationsprobleme mit Server (Wireshark Analyse)

Nicht zwingend, es kann auch kaputtes Bonding sein, entweder durch den Absender (hier eher unwahrscheinlich) oder durch Switches, die per LAG verbunden werden.
Sieht hier aber ehrlich gesagt nicht danach aus, als sei das die Ursache.



Es sieht so aus, dass dein System mit der .212 die TCP-Session verliert und eine neue aufbaut. Dadurch werden dann auch von dessen Seite neue Quellports verwendet. Kommen aber dann noch Pakete auf der alten Session an, werden diese mit RST quittiert, um diese tote Verbindung endgültig zu beenden.
Hier sieht es so aus, als habe der Server (warum auch immer) eine neue TCP-Verbindung geöffnet - von dir eingekreist die Datenübertragungen mit Local-Port 53975.
Von dem Serial-Server kommen aber noch ACKs, scheinbar auf einem alten Port, nämlich 53813.
Von diesem Port aus werden auch die RST-Pakete geschickt, diese sind aber nicht das Problem selbst sondern nur Symptom.


Jetzt kenne ich deine Serial-Server nicht, es gibt aber zwei mögliche Ursachen:

a) Die Duplicate ACKs scheinen Antworten auf SYN-Pakete zu sein (denn Wireshark gibt ihnen die relative Sequenznummer 1).
Hämmert eventuell dein Client zu sehr auf die Serial-Server ein? Diese antworten vielleicht "zu langsam" auf das SYN deines Clients, dieser schickt daraufhin sein SYN nochmal, bekommt dann natürlich irgendwann zwei ACKs als Antwort und einer davon ist dann der Duplicate ACK.
Das könnte erklären, warum es ein schlimmer werdendes Problem ist, wenn der Client immer ungeduldiger und mit mehr Sessions auf die Serial-Server eindrischt und dadurch das Problem verstärkt.
Beende mal testweise, wenn das geht, alle Empfangsprozesse, starte dann einen einzigen und zeichne dabei mit Wireshark auf, was beim Verbindungsaufbau passiert und schaue dir speziell die Antwortzeiten (die Timestamp-Deltas von Wireshark) an. Eventuell muss das System, auf dem die Clients laufen, getuned werden etwas weniger aggressiv zu sein.


b) Die Serial-Server haben ein Netzwerkproblem, verursacht eventuell durch ein Autoneg-Problem, möglicherweise auch durch Duplex-Mismatch. Stelle beide Seiten mal fest auf 10 Mbps Halbduplex ein - das ist das mindeste, auf das sich alle Geräte einigen können. Obacht: Stellst du nur auf Switch-Seite eine fixe Geschwindigkeit und Duplexmodus ein, wird dadurch Autoneg deaktiviert und ohne Autoneg wird von der Gegenstelle immer Halbduplex angenommen! Schaue auch mal im Handbuch, ob die Geräte einen bestimmten Modus hardcoded verwenden, den muss man dann natürlich stattdessen benutzen.

Schau dir auch mal, wenn der Switch das hergibt, die Errorcounter auf allen beteiligten Interfaces an, inklusive eventueller Switch-Uplinks, und natürlich auch die des Systems, wo der Client drauf läuft. Wenn da größer werdende Fehlercounter zu sehen sind, muss man da genauer nachsehen.

Kollege @LordGurke hat ja schon alles Wichtige gesagt.

Da der ja unzweifelhaft TCP als Transportprotokoll nutzt wäre das technisch unmöglich bedingt durch das Handshaking bei einer TCP Session. Man sieht ja auch das das .212er Gerät permanent ein RST (Session Reset) Flag sendet. Von sich aus also die Session beenden will worauf der Server aber nicht reagiert.
So gesehen würde man sagen das die TCP Verbindung zwischen den beiden irgendwie grundsätzlich kaputt ist was oben schon gesagt wurde.
https://www.pico.net/kb/what-is-a-tcp-reset-rst/
https://de.wikipedia.org/wiki/Transmission_Control_Protocol -> "Aufbau TCP Header"

Das kann man ja schnell ändern...
https://de.ryte.com/wiki/TCP
Wie ist das denn auf Twisted Pair Vernetzung adaptiert? Hast du einen Medienwandler dort im Einsatz?
Achte dort auf den Heartbeat Schalter sofern der sowas hat.

Du kannst den Frame ja mitsniffern, was bedeutet das auch alle anderen Beteiligten ihn "sehen". Das kann es also nicht sein! Ggf. muss man den Sniffer direkt an dem Port anschliessen wo das Endgerät ist um auf Nummer sicher zu gehen.

Schwierig ist das keineswegs. Es reicht doch auch wenn du den Wireshark statt Zielgerät aufsteckst. Auch das würde ja sicher verifizieren das der Frame da auch ankommt.
Alternativ eine passive Probe einschleifen: https://greatscottgadgets.com/throwingstar/

Wenn's das denn war bitte nicht vergessen deinen Thread als erledigt zu schliessen!

Wurde dir aber oben auch schon mehrfach gesagt!
Aber gut das du den Fehler gefunden hast!

Aber doch sicher auf die Maschine die daran angeschlossen ist? Du hättest dann einfach nur die Ethernet Strippe aus der Maschine ziehen müssen und in deinen Wireshark Rechner stecken sollen.