Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!usc!ucselx!bionet!parc!zweig From: zweig@parc.xerox.com (Jonathan M. Zweig) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP checksums Message-ID: Date: 29 May 91 23:46:33 GMT References: <3270025@hpctdlb.HP.COM> <1991May28.221045.27724@Think.COM> Sender: news@parc.xerox.com Reply-To: zweig.PARC@Xerox.com Organization: Xerox PARC Lines: 19 In 1's complement arithmetic there are two ways of writing "zero". In C they are 0x0000 and 0xffff (16-bit). I can't see any reason why the checksum would need to always come out to be nonzero (i.e. 0x0000 could happen). Consider the 16-bit ones complement of the 16-bit ones complement sum of a bunch of numbers that happen to add up to 0xffff (such as, say, 0xff00 and 0x00ff with a bunch of 0x0000's too). Yikes! It is all zeroes. The TCP checksum is never optional (though you can use a different one if you like, by supporting RFC1146-style checksum algorithm negotiation), but it is not clear to me that it cann never be all zeroes. In fact, I can't figure out a way that the checksum would ever be 0xffff ("negative zero"). If you can think of a set of 16-bit values whose TCP checksum is 0xffff let me know. Since 0xffff + 0xffff = 0xffff (and not 0x000), I can't figure out a sum that comes out to 0x0000 in order to get complemented to 0xffff by the vanilla TCP checksum algorithm. -Johnny Checksum