Date: Tue, 14 Nov 2000 22:15:18 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Charles Mott <cmott@scientech.com> Cc: Archie Cobbs <archie@dellroad.org>, Ruslan Ermilov <ru@FreeBSD.ORG>, net@FreeBSD.ORG, Ari Suutari <ari@suutari.iki.fi> Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <200011150315.eAF3FIG60231@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 13 Nov 2000 00:29:32 MST." <Pine.BSF.4.21.0011130015100.50906-100000@carcassonne.scientech.com> References: <Pine.BSF.4.21.0011130015100.50906-100000@carcassonne.scientech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. louie > 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 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?200011150315.eAF3FIG60231>