Re: TCP Checksum Interoperability

[Joe Touch <[e-mail]>]

der Mouse wrote:
>>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.

See RFC1624. The definition of 1's complement arithmetic is not 
implementation dependent.

> 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.

That issue is covered in RFC1624 and in RFC768.

>>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.

Again, see RFC1624.

>>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.

Because there's a difference - see RFC768.

Joe