Ask Your Question

(suspected) retransmission

asked 2019-06-19 10:00:16 +0000

Harvey gravatar image

Hello I wrote a lua dissector.

For the frames marked as "(suspected) retransmission" ,

  1. If Allow subdissector to reassemble TCP stream is enable, the dissector is not invoke.
  2. If Allow subdissector to reassemble TCP stream is disable, the dissector shows correct data information only when the packets contain an entire structure, but if there is only the beginning of a new structure it does not work, as it could not reassemble with the next packet.

Is there a way to have both :

  • reassembly of packet from dissector
  • correct display for "(suspected) retransmission" ?
edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2019-07-07 08:29:38 +0000

SYN-bit gravatar image

Hi @Harvey

I looked at your capture file and it seems pretty weird:

  • There is data in the SYN in frame 15
  • I miss the SYN/ACK to the SYN in frame 15
  • There are gaps in the data
  • The sequence numbers don't follow a normal pattern

So either the way the trace was captured messed things up by not capturing all the packets and/or mangling them. Or the TCP stack of the board at hand is very buggy. In either case, since the sequence numbering is way off, the Wireshark TCP dissector can not make sense out of the data to hand over the payload to your sub-dissector properly.

If the problem is persisting, could you make better capture files (one near each of the endpoints would be ideal) and tell us a little more about this setup (what kind of systems are involved, network layout, etc.)?

edit flag offensive delete link more


Note also my comment to my answer (which is not visible unless you click the entirely non-obvious "see more comments" button) which comes to mostly the same conclusions.

grahamb gravatar imagegrahamb ( 2019-07-07 11:52:08 +0000 )edit

Oops, missed that... Still curious on what created such a messy capture file. If it was the capture setup or some broken TCP stack...

SYN-bit gravatar imageSYN-bit ( 2019-07-07 11:58:39 +0000 )edit

I agree about the capture, very odd. Hard to believe it represents a working system.

grahamb gravatar imagegrahamb ( 2019-07-07 13:13:15 +0000 )edit

answered 2019-06-19 10:31:25 +0000

grahamb gravatar image

Not really. When the preference is set to enable, the TCP dissector correctly reassembles the stream such that retransmissions are dropped and sub-dissectors get a "clean" stream.

When the preference is set to disable, then all TCP payloads are handed to the sub-dissectors and they must handle the retransmissions.

If you (and your users) are interested in the application level, then what goes on at the TCP level isn't interesting and allowing the TCP dissector to reassemble the stream correctly is much more productive. The application actually consuming the protocol won't see the retransmission, so in that respect the sub dissector will show what the application receives.

edit flag offensive delete link more


When the preference is set to enable, the TCP dissector correctly reassembles the stream, that's fine !! But unfortunatly for the packet mark as "(suspected) retransmission" the dissector is not called at all, it bothers me a bit.. When disable there is no more such "(suspected) retransmission" ...

Harvey gravatar imageHarvey ( 2019-06-19 12:12:38 +0000 )edit

Why should the TCP dissector call a sub dissector for a retransmission when reassembling the stream? The data is already in the stream, and the sub dissector can't really "use" the duplicated data, and processing it "may" end up corrupting the internal state of the sub dissector.

Why do you need to have the sub dissector called for a retransmission, what problem does this solve?

grahamb gravatar imagegrahamb ( 2019-06-19 12:34:49 +0000 )edit

Because these lines display only raw data, and not "translated" through the dissector. For me these are not really retransmission. If the board on the other end resetted, the tcp communication gets same sequence number as former one, and then marked as duplicate even if these are new streams. It will be fine if I could see pertinant data then.

Harvey gravatar imageHarvey ( 2019-06-19 13:02:15 +0000 )edit

You seem to be implying that these aren't really retransmissions and that Wireshark is misidentifying them? Can you share a capture that shows this?

grahamb gravatar imagegrahamb ( 2019-06-19 13:06:42 +0000 )edit

Hello grahamb, here it is: capture Frames 32,32,34,36 are not really retransmission I think ¯_(ツ)_/¯

Harvey gravatar imageHarvey ( 2019-06-21 11:41:09 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-06-19 10:00:16 +0000

Seen: 5,772 times

Last updated: Jul 07 '19