9

Please find a small pcap file here illustrating my problem.

I have a three-way TCP handshake, followed by two FIX logons. (FIX is a protocol used in trading.) The first FIX logon (frame 4) is interpreted and parsed just fine by WireShark, but the second logon (frame 6) is interpreted as a TCP segment of a reassembled PDU.

However frame 6 is not a TCP segment of a reassembled PDU. It contains a full TCP PDU that should be interpreted and parsed as a FIX logon. I have checked that the sequence numbers, ACK numbers, IP total lengths, etc. are all good.

Why is frame 6 interpreted as a TCP segment of a reassembled PDU?

  • Is there a problem that you're experiencing because of this? – Nathan C Jun 17 '13 at 16:23
  • 1
    Yes, I'm generating all these frames, and there's clearly something wrong with what I did. – Randomblue Jun 17 '13 at 16:24
  • 1
    I would strongly suggest including the salient details of frames 4 and 6 (and perhaps adjacent frames) in your question. The link to the pcap file is great, but only a tiny minority of readers will be inclined to actually download and view it. – Skyhawk Jun 17 '13 at 16:39
  • On first glance, nothing I can find of. Segment 4 is not fragmented. Frame 6 is from destination and you are saying that this frame 6 should be interpreted as the server response of frame 4. i.e the FIX logon should be done there. right. – Soham Chakraborty Jun 17 '13 at 17:01
15

Having the hosts numbered .76 and .67 is a little bit mind-numbing.

Wireshark is calling frame 6 a "TCP segment of a reassembled PDU" because your TCP implementation on 10.10.10.67 is opting to send an ACK w/o payload (a "naked" ACK) rather than including the payload that gets sent in frame 6 w/ the ACK in frame 5. (This is an OS/IP stack-dependent behavior.) This is, in turn, triggering a behavior in the TCP dissector to hand off the payloads from the multiple TCP segments to the FIX dissector. For whatever reason, the FIX dissector isn't interpreting frame 6.

If you turn off the "Allow subdissector to desegment TCP streams" option in the TCP dissector's options you'll find that Wireshark interprets this differently:

Wireshark screenshot

Here's some discussion from the wireshark-users list about the same thing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.