[Guy Harris <gharris@xxxxxxxxx>]

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.