Hi, I'm dealing with a strage problem when using desegmentation, but I don't know for sure is it intended, is it a bug or am I an asshole? :)
I'm dissecting a protocol which consists of a constant length header and a variable length payload following each other in a TCP stream. The payload length is supplied in the header. A payload may be absent and in this case the header provides payload's length of 0 and the next header immediately follows this one. Normally one TCP packet contains both the header, the payload and nothing more. But sometimes it happens that TCP stream gets segmented that is why I use desegmentation funcionality (that one which involves packet_info's can_desegment, desegment_offset and desegment_len fields). But sometimes I get the following situation: 1) The header comes in the end of the packet. It indicates a payload of non-zero length but the actual payload comes in the next packet. 2) After the header is parsed, I check that there is enough data to dissect the payload otherwise I request desegmentation. So according to the 1st item the desegmentation is requested, but desegment_offset is equal to the actual length of the packet, because I don't need the header anymore. 3) The root dissector routine is called for the next packet. The TVB contains the right data - nothing from the previous packet and the whole data with payload from this packet. It has pinfo->fd->flags.visited equals to zero (which is normal AFAIU) *BUT* p_get_proto_data() retuns data associated with the previous frame, which is innormal. At least flags.visited and p_get_proto_data() are both zeroes when desegmentation happens in the usual scenario. So what is happening here? Is it a bug? Or may be I just misuse this feature? -- Max ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
