Shouldn't this be based in part on the result of the TCP checksum? If
the TCP checksum validation fails, the peer is going to discard the
packet and wait for a retransmit. In this case, we should probably be
dissecting the second packet, not the first. There is little value in
attempting to dissect a packet that fails the TCP checksum, as it could
contain complete garbage.
-Devin
On Fri, 2003-02-28 at 05:08, didier wrote:
> Greg Morris wrote:
> > Yes, I understand that the packet is a retransmission and that the
> > packets are being desegmented. But if you look at the frame in packet
> > 7258 you will see the valid data is the same as the segmented data with
> > the exception that the segmented data seems to be off by 1 byte in the
> > starting offset. Is this something that should be looked at? Or can we
> Because it's tcp data from frame 7050 (1 byte) +frame 7258.
> > contribute this to bad data? Is there someone familiar with this part of
> > the code that is investigating or should I try to debug it further?
> It's a bug, retransmitted packets should not be desegmented with frame
> 7258, they are inside frame 709 tcp segment, but 709 is already fully
> decoded.
> >
> >
> > Perhaps if that preference is enabled, the TCP dissector shouldn't
> > supply retransmitted data to subdissectors and shouldn't use it for
> > reassembly - it should just display the data as "Retransmitted data".
> It seems to be the only option if the segment is already decoded by
> subdissector.
>
> Didier
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc