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. L. On Fri, 5 Apr 2002, Chris Trobridge wrote: > I writing to this list because the TCP workgroup was shutdown a while ago. > > 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. > > 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. > > Any thoughts? > > Thanks, > Chris > stupid autoappended signatures below. > > ----------------------------------------------------------------------------------------------------------------- > The information contained in this message is confidential and is intended > for the addressee(s) only. If you have received this message in error or > there are any problems please notify the originator immediately. The > unauthorized use, disclosure, copying or alteration of this message is > strictly forbidden. Baltimore Technologies plc will not be liable for direct, > special, indirect or consequential damages arising from alteration of the > contents of this message by a third party or as a result of any virus being > passed on. > > In addition, certain Marketing collateral may be added from time to time to > promote Baltimore Technologies products, services, Global e-Security or > appearance at trade shows and conferences. > > This footnote confirms that this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including > computer viruses. > > <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>