Re: TCP Checksum Interoperability

[der Mouse <[e-mail]>]

> The TCP (and IP) checksum is defined as "the one's complement of the
> one's-complement sum of the packet contents" [...]

> (The only way to get all 0's as a sum of a one's-complement addition
> process is to to sum a series of zero's - which a real packet will
> never contain.)

...huh?  It depends on how you implement one's-complement arithmetic.

Consider, for example, "do two's-complement adds and reduce the result
mod 0xffff", which may be suitable on a machine with fast hardware mod,
and which can never produce 0xffff.

In 16-bit one's-complement arithmetic, 0x0000 and 0xffff are
equivalent, not only on input but also on output.  Trying to draw an
artificial distinction between them is not only unsupported by the
standard as far as I can tell but liable to break interoperability with
conformant implementations which don't draw that distinction.

> Note that if the packet's check sum (i.e. the sum with the checksum
> field set to zero) happens to come out to zero (i.e. all one's,
> before the complement), then *either* value of zero in the checksum
> field of the packet will result in an all-1's sum when the packet is
> checksummed.

...unless the packet checksumming is done in a way that generates
0x0000 instead of 0xffff when the sum is (one's-complement) zero.

> I honestly don't understand why anyone's code even bothers to look at
> the actual value in the checksum field of the incoming packet; just
> do the checksum of the whole packet, and look at the result.

With that I agree.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [e-mail]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B