Date: Wed, 15 Nov 2000 10:41:06 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Charles Mott <cmott@scientech.com> Cc: Ruslan Ermilov <ru@FreeBSD.ORG>, Archie Cobbs <archie@dellroad.org>, net@FreeBSD.ORG, Ari Suutari <ari@suutari.iki.fi> Subject: Re: libalias: Incremental Update of Internet Checksum Message-ID: <200011151541.eAFFf6G65968@whizzo.transsys.com> In-Reply-To: Your message of "Wed, 15 Nov 2000 08:15:52 MST." <Pine.BSF.4.21.0011150810010.59290-100000@carcassonne.scientech.com> References: <Pine.BSF.4.21.0011150810010.59290-100000@carcassonne.scientech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, 15 Nov 2000, Louis A. Mamakos wrote: > > 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 > > A 1's complement sum of the payload can never be 0x0000 if any > components the payload are non-zero. Therefore a checksum of > 0xffff is not possible, since at least the word containing the > IP protocol byte is non zero. This is explained in RFC 1624. You know, it really depends on how the sum is computed. On the IP stack that I wrote for a UNIVAC 1108, which had one's complement representations of signed integers, the ALU always produced positive zero values when computing the results of an ADD operation. What intermediate values are produced is a function of how you emulate 1's complement arithmetic operations on a 2's complement ALU in your CPU. So your statement about the 1's complement sum never being zero doesn't make sense; by definition it is. Perhaps the fidelity of the emulation is at issue here, rather than the algorithm. > I think that Ruslan has done his homework on this subject, and > there is really no point to dispute the matter further. I suspect the homework to be assigned should be reading some undergraduate computer architecture textbooks. I think it important to consider the checksum operation and how the network protocols use it independently of any particular implementation. 0xFFFE + 0x0001 == 0x0000 on a 16 bit 1's complement CPU with normalized results. This is what the protocol specs assume when they talk about the 1's complement sum. When you take the 1's complement of this value to inserting into the checksum field, you get 0xFFFF (which is still zero) and distinct from 0x0000 which for UDP means "no checksum computed". This special property of 1's complement arithement that results in two representations for zero is used as a hack for the "no checksum" encoding. 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?200011151541.eAFFf6G65968>