Are you using the latest SVN ?
I fixed a bug in pdu tracking/reassembly about ~2 weeks ago
On 9/8/06, John R. <
jhoger@xxxxxxxxx> wrote:OK, so I'm digging into desegment_tcp.
What I find is that when segment B comes it looks for the most recent
prior PDU which it calls msp. It calculates an offset and length for
the last snippet of Segment A. The length is 4, which is the length of
data at the end of Segment A. It uses this info in a call to
fragment_add. Later it gets into the if (ipfd_head) { and creates
next_tvb based on the data in *ipfd_head, and makes this next_tvb a
child of tvb. I'm not sure what the significance of this last step is.
So one of
a) tvb_ensure_length_remaining/compute_offset_length are not working
properly and returning 6 (instead of around 1400 bytes that are in
Segment B).
b) Problem in fragment_add that leaves the length as 6 instead of
~1400... does fragment_add actually affect tvb? It is not clear to me
how the fragment_add, which is passed tvb of Segment B and ipfd_head,
and the next_tvb/tvb child/parent business relate.
It doesn't appear that compute_offset_length peers into child nodes so
I guess fragment_add is the culprit. The tvb would have to consist of
the final desegmented pdu (and then some) once fragment_add returns.
I'm new to this codebase so this stuff is pretty opaque to me. Is
there an architecture document I should be reading first? Anyway, any
explanation of how this desegmentation stuff is supposed to work would
be helpful.
Thanks,
-- John.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
