Lloyd Wood wrote:
See sections 3-5 of RFC1624 for discussion of the one's complement
problem for the IP header checksum. I presume similar applies for TCP,
although I don't know offhand if it's written down anywhere.
RFC793 describes the use of 1's complement as the TCP checksum.
A TCP checksum can never be 0x0000, by the same argument of RFC1624,
since the TCP header length is never 0.
Most of RFC1624 is clarification of the mathematical properties of 1's
complement arithmetic; it's not specific to IP.
We have a compatibility problem between two third party implementations of
the TCP checksum.
The problem concerns the representation of zero, which has two 1-s
complement representations (0000 and ffff).
We don't have source to either stack but I managed to deduce the problem
from looking at a packet trace. The receiver drops all datagrams containing
a TCP with a TCP checksum of ffff.
The receiver appears to be following the checksum procedure in the RFC
literally - ie zero checksum, recalculate and check that the result is the
complement of what the sender sent. The problem is that the sender and
receiver don't agree about zero and hence the datagram is dropped silently.
My view is that the receiver is in error; it should be checking the special
case of 0.
The sender is in error. As noted in RFC1624, there is no summation of
words which yields a 1's complement sum of 0x0000 except all zeroes,
which can't occur because (as above) the TCP header length renders at
least one word non-zero.
Since the TCP checksum is the 1's complement of the sum, and 0x0000
cannot occur as a sum, 0xffff cannot occur as a valid TCP checksum.
It would be useful to check the math used at the source to compute the
checksum. It is likely there is an error, in particular, see section 3
of RFC1624 for one typical one.
All the receiver code I have seen doesn't work this way. The normal
approach is to calculate the1-s complement sum with checksum in place and
check that this is zero. The methods I konw always return just one
representation for zero, hence there is no special case.
As per RFC1624, that depends on the inputs. Nonzero inputs generate only
0xffff as a sum, it takes all-zeroes to generate 0x0000 as a sum, but,
as per above, that can't occur.
Joe