Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!zweig
From: zweig@p.cs.uiuc.edu
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP-IP zero checksum
Message-ID: <93400014@p.cs.uiuc.edu>
Date: 13 Mar 89 17:44:00 GMT
References: <107@nixvia.UUCP>
Lines: 32
Nf-ID: #R:nixvia.UUCP:107:p.cs.uiuc.edu:93400014:000:1350
Nf-From: p.cs.uiuc.edu!zweig    Mar 13 11:44:00 1989


> /* Written  6:42 pm  Mar  7, 1989 by cdh@bbn.com 
> I think the rational about always using the FFFF version of 0 in the
> ones-complement checksum of TCP was that it prevented an all-zeros
> packet from being legal.  Therefore, if some interface or memory
> fed you a packet containing all zeros, you knew it was illegal, since
> a correct all-zeros packet would have checksum FFFF.
> 
> Of course, I could be wrong.
> 
> Carl

That's why the definition is the complement of the sum of all the 16-bit
words in the datagram. All 0's add to 0000 which then gets complemented
to FFFF. A packet that contained 0000FFFF0000FFFF0000FFFF... might be
the result of some hardware messup (half the data lines jammed on a memory
board) but seems unlikely. Still only has a 50/50 chance of getting 0000
as a checksum.

Ignoring checksums in TCP/IP is like giving a bucket o' pork ribs to
someone to celebrate a barmitzvah -- it runs counter to the principle
of reliable stream transport.


Johnny Zweig
University of Illinois at Urbana-Champaign
Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------