Date: Wed, 15 Nov 2000 10:48:19 -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: <200011151548.eAFFmJG66031@whizzo.transsys.com> In-Reply-To: Your message of "Wed, 15 Nov 2000 17:24:35 %2B0200." <20001115172435.A9724@sunbay.com> References: <Pine.BSF.4.21.0011130015100.50906-100000@carcassonne.scientech.com> <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> If I compute the sum on IP PACKET, then sum can't be zero, so checksum can > never be a 0xffff. This is all explained in RFC 1624, BTW :-) I can see you you would think this, given the errornous statement from the RFC: In one's complement, there are two representations of zero: the all zero and the all one bit values, often referred to as +0 and -0. One's complement addition of non-zero inputs can produce -0 as a result, but never +0. Since there is guaranteed to be at least one non-zero field in the IP header, and the checksum field in the protocol header is the complement of the sum, the checksum field can never contain ~(+0), which is -0 (0xFFFF). It can, however, contain ~(-0), which is +0 (0x0000). However, having actually used 1's complement-based ALU's, I can assure you that one's complement addition of non-zero inputs certainlly can produce +0 as the result. I have the core plane from that machine in my office as proof :-) 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?200011151548.eAFFmJG66031>