14.05.2023

2622

TCPIP Kommunikationsprobleme mit Server (Wireshark Analyse)

Hallo zusammen,

ich habe hier einen Mitschnitt zwischen zwei Teilnehmern. Das eine ist ein Prozess (IP: 212) der Daten per TCP empfängt von einem Server (IP: 206) welcher mehrere serielle Schnittstellen über TCP zur Verfügung stellt.

Der Prozess verbindet sich auf die seriellen Schnittstellen über die TCP-Ports 2100, 2200, 2300, 2400 ... (Ports 1 bis 4).
Jetzt gibt es immer wieder Verbindungsabbrüche.

Daher habe ich auf den Ports mal die Pakete mitgeschnitten und irgendwas ist hier offensichtlich faul.
Ständig gibt es "TCP DUP ACK" und "RST". Ich vermute das Problem aber beim Server (IP: 206) da andere Dienste sauber laufen.

Noch zur Info: Die Kiste auf der die Prozesse laufen unterstützt bis zu 1000Mbit über die Netzwerkkarte. Der Server mit den seriellen Ports lediglich 10Mbit.

Das Problem trat schon immer mal monatlich auf, jedoch in letzter Zeit ganz extrem (mehrmals täglich)!

Ich wäre dankbar über eure Hilfe. Vielleicht hat das schonmal jemand gesehen.
Im Anhang Screenshots von drei Ports an dem Server. Merkwürdig auch, dass ein Port garnicht funktioniert. Einer teilweise und einer relativ gut. Das Problemkind ist hauptsächlich das auf Port 2200. 2100 scheint aber garnichts zu machen.

Danke!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7148235421

Url: https://administrator.de/contentid/7148235421

Ausgedruckt am: 24.11.2024 um 14:11 Uhr

20 Kommentare

Neuester Kommentar

Gründe für Duplicate ACKs sind immer Paketverluste:
https://accedian.com/blog/network-packet-loss-retransmissions-and-duplic ....
https://osqa-ask.wireshark.org/questions/29216/why-are-duplicate-tcp-ack ...
Usw. usw.

Die Gründe dafür können vielfältiger Natur sein. Dazu müsste man den genauen Pfad kennen und was für Komponenten in ihm liegen zwischen den Kommunikationspartnern.
Typische Fehler sind Speed und Duplex Negotiation Mismatches des Servers oder Clients am LAN Switch.
Sprich die Endgeräte können sich nicht korrekt auf einem Linkspeed und Duplex Mode einigen. Der Fehler ist tückisch weil mit steigendem Traffic auch die Fehlerrate exponentiell steigt.
Hier hilft die Error Counter am Port zu betrachten und Speed und Duplex Werte einmal statisch und beidseitig zu setzen oder einfach einmal testweise einen 2ten Switch dazwischenzuhängen um zu sehen ob die Fehler verschwinden was dann dieses Problematik verifiziert.
Es können aber auch defekte NICs, Optiken (SFPs etc.) und auch Patchkabel oder DAC/Twinax oder LWL Kabel sein.

Besten Dank.

Was ich jedoch nicht verstehe ist, dass „DUP ACK“ kommt hier von 206. 206 ist der Server der die seriellen Daten weiterleitet an 212. Der Prozess auf der Kiste 212 empfängt die Daten nur und sendet NICHTS.
Wie kann da bei dem Server 206 der Zustand entstehen dass es zu Paketloss kommt und warum antworten wir darauf mit einem RST? Das RST beendet doch eig die Verbindung und dennoch sieht man oben, dass Daten ankommen.

Zitat von @aqui:
Gründe für Duplicate ACKs sind immer Paketverluste

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.

Zitat von @byt0xm:
Wie kann da bei dem Server 206 der Zustand entstehen dass es zu Paketloss kommt und warum antworten wir darauf mit einem RST? Das RST beendet doch eig die Verbindung und dennoch sieht man oben, dass Daten ankommen.

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.

Der Prozess auf der Kiste 212 empfängt die Daten nur und sendet NICHTS.

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"

Ist natürlich korrekt. Mit Senden meinte ich Senden (PSH) in Form von Daten an die nächste Schicht. Dafür kenne ich mich offensichtlich nicht gut genug mit TCP aus. Aber nach Gurkes Beitrag scheint auch auf ein SYN ein DUP ACK möglich zu sein.

Danke für eure Beiträge, dass hilft mir schonmal weiter an welchen Stellen ich ansetzen kann.

Ich werde auch mal sehen zu welchen Prozessen die lokalen Ports gehören und ob die noch laufen. Nicht dass da mehrere Prozesse laufen was unweigerlich zu Problemen führen würde, da die Terminalserver nur eine Verbindung pro Port zulassen.
Allerding halte ich das für nahezu ausgeschlossen, da der Prozess ein Systemdienst ist.

Der Terminalserve rist ein alter xyplex mx-1600 https://www.manualslib.com/manual/815277/Xyplex-Maxserver-1600.html

Bin echt am überlegen was das sein kann. Hatte auch schon die alten EEPROMS im Verdacht des Terminalservers, glaube aber aktuell eher an die Auto Negotiation Theorie weil 10MBit <-> 1000MBit bzw. Duplex/Halbduplex.

Da das Din gThinwire nutzt und ich sehe dass es ein Koaxialkabel ist, denke ich auch das da mehr als Halbduplex nicht möglich ist, dass kommt wohl erschwerend hinzu.

Dafür kenne ich mich offensichtlich nicht gut genug mit TCP aus

Das kann man ja schnell ändern...

https://de.ryte.com/wiki/TCP

Da das Din gThinwire nutzt und ich sehe dass es ein Koaxialkabel ist, denke ich auch das da mehr als Halbduplex nicht möglich ist

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.

Leider bin ich nicht vor Ort nur Remote. Aber ich werd’s in Erfahrung bringen.

Zitat von @aqui:

Dafür kenne ich mich offensichtlich nicht gut genug mit TCP aus

Das kann man ja schnell ändern...

https://de.ryte.com/wiki/TCP

:D ja das is ja alles bekannt. Hier wird’s interessant: https://datatracker.ietf.org/doc/html/rfc793
Aber mit schnell is da nix. Kommt aber wohl jetzt. Konnt mich immer drum drücken ;)

So, im Anhang ein Bild. Man sieht, dass er sauber eine Verbindung aufbauen will.
Aber der 206 scheint das ACK nicht zu bekommen und fordert es in dem DUP ACK dann an.

Meine Frage nun: Wie kann es sein, dass wir ihm das "verloren" gegangene ACK nicht einfach zusenden?

ich denke ich komme der Sache näher ;)

Man sieht auch, dass das ACK auf das SYN ACK in nichtmal 45µS kommt. Ist das zu schnell für 10Mbit halbduplex? Aber das Switch müsste das doch beachten. Da gabs doch mal was mit 1000µS Delay ... das is aber schon so lange her.

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.

Ich sniffe ja am Gerät von dem es gesendet wird. Natürlich sehe ich ihn. Aber er scheint nicht anzukommen. Um das zu beweisen, stimmt, müsste ich mich vor das Zielgerät schalten. Schwierig.

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!

Ist leider noch nicht ganz klar ob es dass war. Aber ich werde daran denken ;)

Also. Ursache war, dass ein Prozess der IT Abteilung auf offene Ports geprüft hat. Da die Terminalserver nur eine averbinding zulassen, haben diese nach dem „Port Check“ die alte Verbindung abgebaut/ignoriert.
Hätte man direkt am Port die Pakete mitgelesen wäre dass aufgefallen!

Danke für die Hilfe!

Hätte man direkt am Port die Pakete mitgelesen wäre dass aufgefallen!

Wurde dir aber oben auch schon mehrfach gesagt!

Aber gut das du den Fehler gefunden hast!

Ja stimmt. Wir haben nur keinen Zugriff auf den Port. Das is das Problem

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.