Warum glaubt WireShark, dass dieser Frame ein TCP-Segment einer wieder zusammengesetzten PDU ist?

Hier finden Sie eine kleine PCAP-Datei , die mein Problem veranschaulicht.

Ich habe einen Drei-Wege-TCP-Handshake, gefolgt von zwei FIX-Anmeldungen. (FIX ist ein Protokoll, das im Handel verwendet wird.) Die erste FIX-Anmeldung (Frame 4) wird von WireShark einwandfrei interpretiert und analysiert, die zweite Anmeldung (Frame 6) wird jedoch als a interpretiert TCP segment of a reassembled PDU.

Frame 6 ist jedoch kein TCP-Segment einer wieder zusammengesetzten PDU. Es enthält eine vollständige TCP-PDU, die als FIX-Anmeldung interpretiert und analysiert werden sollte. Ich habe überprüft, ob die Sequenznummern, ACK-Nummern, IP-Gesamtlängen usw. alle gut sind.

Warum wird Frame 6 als TCP-Segment einer wieder zusammengesetzten PDU interpretiert?

tcp wireshark

— Zufälliges Blau
quelle

Gibt es ein Problem, das aufgrund dessen auftritt?

— Nathan C

Ja, ich generiere all diese Frames und es stimmt eindeutig etwas nicht mit dem, was ich getan habe.

— Randomblue

Ich würde dringend empfehlen, die wichtigsten Details der Bilder 4 und 6 (und möglicherweise benachbarter Bilder) in Ihre Frage aufzunehmen. Der Link zur pcap-Datei ist großartig, aber nur eine winzige Minderheit der Leser wird dazu neigen, sie tatsächlich herunterzuladen und anzuzeigen.

— Skyhawk

Auf den ersten Blick nichts, was ich finden kann. Segment 4 ist nicht fragmentiert. Frame 6 ist vom Ziel und Sie sagen, dass dieser Frame 6 als Serverantwort von Frame 4 interpretiert werden sollte, dh die FIX-Anmeldung sollte dort erfolgen. richtig.

— Soham Chakraborty

Die Hosts mit den Nummern .76 und .67 zu haben, ist ein bisschen nervenaufreibend.

Wireshark nennt Frame 6 ein "TCP-Segment einer neu zusammengesetzten PDU", da Ihre TCP-Implementierung am 10.10.10.67 sich dafür entscheidet, eine ACK ohne Nutzlast (eine "nackte" ACK) zu senden, anstatt die in Frame 6 gesendete Nutzlast einzuschließen w / the ACK in Frame 5. (Dies ist ein OS / IP-Stack-abhängiges Verhalten.) Dies löst wiederum ein Verhalten im TCP-Dissektor aus, um die Nutzdaten von den mehreren TCP-Segmenten an den FIX-Dissektor zu übergeben. Aus irgendeinem Grund interpretiert der FIX-Dissektor Frame 6 nicht.

Wenn Sie die Option "Subdissektor erlauben, TCP-Streams zu desegmentieren" in den Optionen des TCP-Dissektors deaktivieren, werden Sie feststellen, dass Wireshark dies anders interpretiert:

Wireshark Screenshot

Hier ist eine Diskussion aus der Liste der Wireshark-Benutzer über dasselbe .

— Evan Anderson
quelle