Ask Your Question
0

Why doesn't wireshark dissect packets that have both retransmitted and new data?

asked 2019-01-15 22:15:59 +0000

neshone gravatar image

I have a Lua dissector for my custom protocol. The dissector works fine and reassembles PDUs well in all but one use case:

When TCP ZeroWindowProbe happens because of the full window, one byte of data is sent. My dissector rightly detects that this is not enough for the header and asks for more data (by setting pinfo.desegment_len = DESEGMENT_ONE_MORE_SEGMENT). The problem is that when ACK is finally received, the new packet sent includes the one byte used for probe (as well as additional 1459 bytes of new data) and the whole packet gets treated as a retransmission.

Because retransmission is treated as error, the dissector is never called. This breaks any further dissecting, because I have no way of finding the beginning of a packet in my protocol and the sent packet doesn't contain the whole number of messages (if cuts the last message in the middle of the header).

I tried turning off the "Do not call subdissectors for error packets" and in that case the dissector gets called, but when I try to signal that I need more data (when I get to the last, partial message in the packet), this is ignored and the next packet is not dissected as it should.

Am I doing aniything wrong? How is this situation meant to be handled in the dissector?

I'm using wireshark 2.6.4.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-01-15 22:55:18 +0000

Guy Harris gravatar image

Retransmissions shouldn't be treated as "errors" in the sense of "error packets" - "error packet" refers to ICMP/ICMPv6/etc. packets, where some or all of the packet that caused the error is included in the error report packet; that preference causes the TCP dissector to check whether the TCP segment it's dissecting is part of an error report packet and, if so, not to hand the packet to sub dissectors.

If changing the setting of "Do not call subdissectors for error packets" makes a difference in the way your trace is dissected, that should only be due to the packet in question being in an ICMP/ICMPv6 error report. If that's not what's happening, file a bug report on the Wireshark bugzilla.

If the TCP dissector is treating a TCP segment that's not in an ICMP/ICMPv6 error report, and that contains some retransmitted data plus some new data, as not containing any new data to be handed to subdissectors, that's also a bug; if that's happening, file a bug report on the Wireshark bugzilla.

Please attach a sample capture file that exhibits the problem to any bug you file. (Sample capture file, not a screenshot of the Wireshark dissection of the file.)

edit flag offensive delete link more

Comments

I don't know about ICMP error reports (my capture doesn't show any ICMP packets), but your second "if" is true in my case - TCP dissector doesn't pass new data to my dissector and that new data is transmitted along with one byte that is retransmitted, all in the same packet.

It might be important to note that turning off option "Do not call subdissectors for error packets" alone didn't have any effect - I also had to turn off option "Allow subdissectors to reassemble TCP streams".

I also found this bug that seems related, but I'm not sure: https://bugs.wireshark.org/bugzilla/s...

If this still sounds like a bug to you, I'll file a bug report with the captured TCP data as soon as I can. I can probably also strip down our dissector to be simple and reproduce the problem.

neshone gravatar imageneshone ( 2019-01-16 16:18:22 +0000 )edit

It appears that "Do not call subdissectors for error packets" is badly named; it affects retransmissions, rather than explicitly checking for error packets. Perhaps there should be special treatment for error packets, i.e. packets contained in error reports from ICMP/ICMPv6, but that should be based on "is this from an error packet?", not "is this a retransmission?"

I would file this as a separate bug; if it ends up having the same cause as the other bug, it can be closed as a duplicate.

Guy Harris gravatar imageGuy Harris ( 2019-01-16 18:32:26 +0000 )edit

Bug report filed. Link for future reference: https://bugs.wireshark.org/bugzilla/s...

neshone gravatar imageneshone ( 2019-01-19 13:12:15 +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

Stats

Asked: 2019-01-15 22:15:59 +0000

Seen: 1,467 times

Last updated: Jan 15 '19