Wireshark-dev: [Wireshark-dev] TCP Continuation - with reassembly turned off
From: Jeff Morriss <[email protected]>
Date: Tue, 27 Nov 2018 21:09:44 -0500
Hi list,

Looking a capture file[1] I've noticed something funny in master: even if I turned off the TCP reassembly preference (Allow subdissector to reassemble TCP streams) I still get "[Continuation to #XXXX]" in the Info column and the payload is not handed to the subdissector.

For example frame 11214 is just TCP in master but (with the same preference options) it is decoded as Diameter in master-2.6.

To get such frames decoded as Diameter in master I need to disable the "Analyze TCP Sequence Numbers" preference.

Obviously this isn't right; TCP is trying to deal with multi-segment PDUs even when reassembly is turned off.  The question is: is there some value to trying to desegment while not reassembling (meaning: only try to dissect the first part of what the upper-layer protocol says is a PDU while labeling the rest continuations but while *not* chewing up memory with reassembled PDUs)?  I.e., should disabling this be Yet Another Preference?  I'm inclined to say "no" but thought I'd ask...

Note: this capture is interesting for this because there are plenty of missed frames; thanks to the recent I73694a085bbafb3ae280e02fa4c9e26868b31f76 the Diameter dissector is claiming lots of frames into giant PDUs (because it got what it thought was a valid Diameter message with a very large length field).