(suspected) retransmission

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

Harvey
9 ●1 ●9 ●8

Hello I wrote a lua dissector.

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

If Allow subdissector to reassemble TCP stream is enable, the dissector is not invoke.
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

add a comment

2 Answers

Sort by » oldest newest most voted

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

SYN-bit

18528 ●9 ●339 ●255 https://SYN-b.it

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

Comments

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 ( 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 ( 2019-07-07 11:58:39 +0000 )edit

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

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

add a comment

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

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●973 ●227 https://www.wireshark.org

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

Comments

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 ( 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 ( 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 ( 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 ( 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 ( 2019-06-21 11:41:09 +0000 )edit

That's quite an odd capture and it has confused Wireshark (and me). Add a column for TCP Sequence Number (tcp.seq) and you can see some very odd jumps. Assume that .83 is the server and .200 is the client.

The capture starts off with some regular conversation (frames 1-14), then frame 15 appears to be the start of a new conversation (SYN) but reusing the same ports either end (flagged by Wireshark as port reuse) and it also has 13 bytes of data.

Frame 16 then sends more data, but the sequence number is incorrect it should be 112513 (frame 15 seq. was 112500 + 13 bytes of data), hence Wireshark marks it as a retransmission as it overlaps the sequence range implied by frame 15.

Frame 17 is a reply, acking the data sent by frame 16, sending 15 bytes of data BUT the SYN has NOT been ...(more)

grahamb ( 2019-06-21 13:01:50 +0000 )edit

Thank you for your expertise, it is very interresting for me. I still continue to analyze on my side

Harvey ( 2019-06-28 07:14:37 +0000 )edit

add a comment

Your Answer

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

Add Answer

(suspected) retransmission

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

(suspected) retransmission edit

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

(suspected) retransmission