From owner-freebsd-net Wed Nov 15 8: 9:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id ABE1837B4CF for ; Wed, 15 Nov 2000 08:09:19 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id eAFG8gb12929; Wed, 15 Nov 2000 18:08:42 +0200 (EET) (envelope-from ru) Date: Wed, 15 Nov 2000 18:08:42 +0200 From: Ruslan Ermilov To: "Louis A. Mamakos" Cc: Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <20001115180842.A11913@sunbay.com> Mail-Followup-To: "Louis A. Mamakos" , Charles Mott , Archie Cobbs , net@FreeBSD.ORG, Ari Suutari References: <200011150315.eAF3FIG60231@whizzo.transsys.com> <20001115100407.D36400@sunbay.com> <200011151436.eAFEaHG65417@whizzo.transsys.com> <20001115172435.A9724@sunbay.com> <200011151548.eAFFmJG66031@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011151548.eAFFmJG66031@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Nov 15, 2000 at 10:48:19AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Nov 15, 2000 at 10:48:19AM -0500, Louis A. Mamakos wrote: > > > 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 :-) > If the above would be true that would mean that almost all implementations of computing the checksum are wrong, i.e. they produce the value of 0x0000 as a checksum when it should actually be 0xffff. That would also mean all three RFCs: 1071, 1141 and 1624 are wrong. I can't believe that! My understanding of the one's complement sum is as follows: This is the sum (or an algorithm to compute such a sum), which produces the RIGHT results for items represented in one's complement form, the form in which negative numbers are represented by one's complements of a positive number. You mentioned the books... Can you citate from one of these books that states that 0xFFFF + 0x0001 in one's complement arithmetic is 0x0000 rather than 0xFFFF? -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message