TCP Continuation - with reassembly turned off

[Jeff Morriss <jeff.morriss.ws () gmail com>]

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.

[1] https://www.cloudshark.org/captures/6cf577bd1721

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).

Regards,
-Jeff

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe