[Richard van der Hoff <richardv@xxxxxxxxxxxxx>]

Reply from original poster attached.

--- Begin Message ---

From: Michael Ngo <mn17962@xxxxxxxxx>

Date: Thu, 9 Aug 2007 16:05:52 -0700 (PDT)

Richard

I looked over the capture one more time, and I don't
think the reassembler itself is buggy, but the way
packets are examined. To be more specific, when I was
reassembling the packets, it reached the frame with
the lost-segment/out-of-order packet. When it reached
this packet, which was out of sequence (based on tcp
sequence numbers), my dissector read the wrong bytes
thus leading to the wrong length. So basically if the
initial run through the packets, went in order by
sequence number and not by frame number, the
reassembler would have picked up the out-of-order
packet later and reassemble it correctly. Sorry, for
any confusion. 

Mike Ngo 

Note: forwarded message attached.



      ____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

--- Begin Message ---

From: Michael Ngo <mn17962@xxxxxxxxx>

Date: Wed, 8 Aug 2007 17:29:51 -0700 (PDT)

I attached an example as Richard asked. The sequence
numbers I refer to, are relative sequence numbers.
Also this is not a complete capture, I filtered out
enough packets for explanation purposes. So the
situation is that frame 3 is an out-of-order packet
with sequence number 10876 and length 1058. There is
also frame 16, which has sequence number 11680 and
length 1460. So by looking at this, there is a segment
overlap between the two. So when I call the
tcp_dissect_pdus function in my dissector, it attempts
to reassemble with the wrong length. This length is
miscalculated when it reads the first 12 bytes from
the reassembled frames 3, 16, 17, and so on, in that
order. The correct behavior that I am expecting is
that the suspected retransmissions in frames 5, 7, 8,
10, 11, 12, 14, 15, and 16 are not really
retransmissions. So the reassembler should continue
assembling frames, at frame 5 and then stick in frame
3 where it fits. However in this example, frame 3
overlaps with other frames so it will be redundant
data. So now I have another question. Is there some
option or flag I have to check/change in order for the
assembler to not copy the redundant data?

Mike

--- Richard van der Hoff <richardv@xxxxxxxxxxxxx>
wrote:

> On Wed, 8 Aug 2007, Michael Ngo wrote:
> 
> > Hi
> >
> > I'm not sure if the reassembler is buggy or if I
> am
> > using it wrong. I'm using it like this
> >
> > tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 12,
> > get_foo_length, dissect_foo_message)
> >
> > where get_foo_length returns the length of the
> packet
> > and dissect_foo_message is my dissector.
> 
> <snip>
> 
> I'm totally confused by your description. But
> wiresharks' attempts at 
> packet reassembly in the face of retransmissions and
> out-of-order packets
> are inherently a bit best-effort, as it has to be
> able to do a reasonable 
> job at reassembly with potentially only a single
> pass through the traffic. 
> If you really think it could do better, could you
> supply an example 
> capture with an explanation as to what it's doing
> wrong?
> 
> Cheers
> 
> Richard
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
>
http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 



       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 

Attachment: test.pcap
Description: 524190959-test.pcap

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev

--- End Message ---

--- End Message ---