Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Nov 2000 09:36:17 -0500
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        Ruslan Ermilov <ru@FreeBSD.ORG>
Cc:        Charles Mott <cmott@scientech.com>, Archie Cobbs <archie@dellroad.org>, net@FreeBSD.ORG, Ari Suutari <ari@suutari.iki.fi>
Subject:   Re: libalias: Incremental Update of Internet Checksum 
Message-ID:  <200011151436.eAFEaHG65417@whizzo.transsys.com>
In-Reply-To: Your message of "Wed, 15 Nov 2000 10:04:07 %2B0200." <20001115100407.D36400@sunbay.com> 
References:  <Pine.BSF.4.21.0011130015100.50906-100000@carcassonne.scientech.com> <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, Nov 14, 2000 at 10:15:18PM -0500, Louis A. Mamakos wrote:
> > 
> > Arithmetically, a value of 0xffff is identical to 0x0000 since they
> > both represent the value of zero when using a one's complement binary
> > representation of values.  
> > 
> Except you can't actually receive the value of 0xffff in a checksum field.
> One's complement sum is guaranteed to be non-zero except if all items are
> zeroes.  Since IP Protocol field is a non-zero value that participates in
> all checksums (IP, TCP, UDP, ICMP), the checksum value (which is a one's
> complement of a one's complement sum) is guaranteed to be non-0xffff.

For other than UDP, it really doesn't make a difference if the value of
the checksum field is 0x0000 (+0) or 0xffff (-0); they both have the
(1's complement arithmetic) value of zero.

> > It turns that this property is used in some network protocols (e.g., UDP) 
> > to distinguish between a checksum value that's computed as zero (represented
> > as 0xffff in the packet) from a packet which has no computed checksum at all.
> > This was done in the dark ages when it was deemed "too expensive" to
> > compute a checksum.
> > 
> >From the above it follows that UDP should better be using 0xffff rather than
> 0x0 to indicate that a packet has no computed checksum.  It is quite possible
> that the computed checksum will have a zero value, in which case the receiving
> UDP module will consider such a packet as with no computed checksum, which is
> wrong.

But the checksum is supposed to be the one's complement of the checksum
of the payload (which is computed using one's complement arithmetic).  If
you compute a checksum, and the value is zero, you insert the complemented
value (0xffff) into the packet.  

louie


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011151436.eAFEaHG65417>