From owner-freebsd-net Sun Nov 12 23:31: 7 2000 Delivered-To: freebsd-net@freebsd.org Received: from if.scientech.com (mail.rv.scientech.com [198.60.89.9]) by hub.freebsd.org (Postfix) with ESMTP id 3E8CB37B479; Sun, 12 Nov 2000 23:31:04 -0800 (PST) Received: from carcassonne (carcassonne.scientech.com [10.10.25.250]) by if.scientech.com (8.9.3/8.9.3) with ESMTP id AAA32248; Mon, 13 Nov 2000 00:29:32 -0700 Date: Mon, 13 Nov 2000 00:29:32 -0700 (MST) From: Charles Mott To: Archie Cobbs Cc: Ruslan Ermilov , net@FreeBSD.ORG, Ari Suutari Subject: Re: libalias: Incremental Update of Internet Checksum In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, ok -- Ruslan is mathematically correct, but the problem is really neglible, because of how checksums are commonly verified. Even if DifferentialChecksum() incorrectly produces a 0xffff instead of 0x0000, this error does not affect the verification sum computed by a recipient machine. To quote from RF 1624: If an end system verifies the checksum by including the checksum field itself in the one's complement sum and then comparing the result against -0, as recommended by RFC 1071, it does not matter if an intermediate system generated a -0 instead of +0 due to the RFC 1141 property described here. It would be interesting to do some network surveillance to see how often 0xffff shows up in checksum fields. -- Charles Mott On Sun, 12 Nov 2000, Charles Mott wrote: > On Sun, 12 Nov 2000, Archie Cobbs wrote: > > Ruslan Ermilov writes: > > > The DifferentialChecksum() function in libalias(3) is used > > > to efficiently recompute the checksum for altered packets. > > > Unfortunately, the implementation suffers from the problem > > > described in RFC 1624. I have implemented the replacement > > > for it, using the final formula [4] from the RFC. > > > > > > The attached C program demonstrates the problem as well as > > > the new implementation. > > > > > > Comments? > > > > Wow.. seems like a pretty important thing to fix. > > We should try to get this into 4.2 if possible. > > I haven't studied the arithmetic yet, but the problem > cannot be too serious, or a lot of things would break. > My guess is that this has to be an "edge effect". > Since Ruslan's example program showed a delta of 1 > for so many cases, I'm not sure what it means yet. > > I would agree that if there is a problem, it should > be fixed. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message