> On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote:
> >
> > > > So that the same logic applies to TCP packets as well. Currently, we
> > > > can send a TCP packet with a checksum of 0, which is legal. Of possible
> > > > interest is that Linux doesn't do this; they alwyas send a non-zero
> > > > checksum in the TCP case, if a checksum was computed.
> > > >
> > > Hmm, but why would we do this for TCP? This violates RFC 793.
> > > AFAIK, only UDP checksums are special.
> >
> > 0x0000 and 0xFFFF are both 16-bit 1's complement representations of
> > zero, so you could send either and still have the remote TCP validate
> > the checksum.
> >
> Louis, I recall our long discussion on the topic. It depends on how
> remote end verifies the checksum. It it uses the value in checksum
> field, then it is irrelevant. If it recomputes the checksum from
> scratch, it does matter, and they won't match if you replace 0x0000
> computed checksum by 0xffff.
>
> And after I read Stevens, I still think they are the different values,
> and you can't receive zero for a two's complement sum if at least one
> item is non-zero. Therefore, checksum computed on any valid IP packet
> is guaranteed to be non-0xffff. That's why UDP uses zero to indicate
> no-checksum, and requires to replace 0xffff by 0.
Whatever. Both +0 and -0 in 1's complement arithemetic are equivelent,
just as a normalized and non-normalized floating point representation
of the same value are "equal" even though the bit patterns are different.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
