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