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-requ...@wireshark.org?subject=unsubscribe
