On Tue, 22 Nov 2005, Guy Harris wrote:
> Jaap Keuter wrote:
>
> > It seems that inhibiting desegmentation i.c.o. TCP checksum error is
> > rather old (svn blame says guy, revision 4571).
>
> No, revision r3923, which was a checkin of code by Ronnie.
>
> Revision 4571 added a preference to inhibit the *checking* of the
> checksum, to deal with systems doing checksum offloading:
>
> r4571 | guy | 2002-01-18 14:35:19 -0800 (Fri, 18 Jan 2002) | 9 lines
>
> Add an option to turn off TCP checksum checking (and to *allow*
> desegmentation even though we don't know whether the checksum is valid).
> I've seen packets with bad TCP checksums in Solaris network traces, but
> the traffic appears to indicate that the packet *was* received; I
> suspect the packets were sent by the host on which the capture was being
> done, on a network interface to which checksumming was offloaded, so
> that DLPI supplied an un-checksummed packet to the capture program but a
> checksummed packet got put onto the wire.
>
> > My guess is that Ethereal
> > used to break badly when out-of-bound operations were performed, which a
> > TCP checksum error may predict.
>
> No, as I remember, Ronnie's rationale was that if the header was
> damaged, you couldn't rely on its contents, and thus shouldn't do
> reassembly, as that relies on the TCP sequence number in the header, and
> that this wasn't to prevent crashes, it was to prevent bogus reassembly.
>
> > Nowadays we have nice exception handling,
> > so IMHO this preventive measure may be relaxed.
>
> If by "nice exception handling" you mean the tvbuff stuff, that was in
> place at the time the TCP reassembly was added.
Thank you for the explanation. It sounds all very reasonable. It's a
trade off, which can be selected by the preference "Validate the TCP
checksum".
This means that my patch can be applied, making sure that for the
captured, not desegmented PDU, a non-oversized tvb_subset is created
which can be dissected as far as it goes.
Thanx,
Jaap