Date: Wed, 7 Mar 2001 17:19:56 +0200 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Jonathan Lemon <jlemon@FreeBSD.ORG>, net@FreeBSD.ORG Subject: Re: Delayed checksums commit broke UDP checksum calculation Message-ID: <20010307171956.B36537@sunbay.com> In-Reply-To: <200103071458.f27EwWa99960@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Mar 07, 2001 at 09:58:32AM -0500 References: <20001116120936.A45755@sunbay.com> <20001116091954.A19895@prism.flugsvamp.com> <20010307123156.A19829@sunbay.com> <200103071440.f27EeYa99809@whizzo.transsys.com> <20010307164822.E97252@sunbay.com> <200103071458.f27EwWa99960@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 07, 2001 at 09:58:32AM -0500, Louis A. Mamakos wrote: > > On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote: > > > > > > > > So that the same logic applies to TCP packets as well. Currently, we > > > > > can send a TCP packet with a checksum of 0, which is legal. Of possible > > > > > interest is that Linux doesn't do this; they alwyas send a non-zero > > > > > checksum in the TCP case, if a checksum was computed. > > > > > > > > > Hmm, but why would we do this for TCP? This violates RFC 793. > > > > AFAIK, only UDP checksums are special. > > > > > > 0x0000 and 0xFFFF are both 16-bit 1's complement representations of > > > zero, so you could send either and still have the remote TCP validate > > > the checksum. > > > > > Louis, I recall our long discussion on the topic. It depends on how > > remote end verifies the checksum. It it uses the value in checksum > > field, then it is irrelevant. If it recomputes the checksum from > > scratch, it does matter, and they won't match if you replace 0x0000 > > computed checksum by 0xffff. > > > > And after I read Stevens, I still think they are the different values, > > and you can't receive zero for a two's complement sum if at least one > > item is non-zero. Therefore, checksum computed on any valid IP packet > > is guaranteed to be non-0xffff. That's why UDP uses zero to indicate > > no-checksum, and requires to replace 0xffff by 0. > > Whatever. Both +0 and -0 in 1's complement arithemetic are equivelent, > just as a normalized and non-normalized floating point representation > of the same value are "equal" even though the bit patterns are different. > In two's complement arithmetics, yes. What matters here is how the the real checkers are implemented. For BSD-derived implementations, this does not matter. I don't know if others really exist. RFC 1624 is pretty clear on this topic. The usual Internet principle is in place (from RFC 791): "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." To be CONSERVATIVE, the implementation MUST NOT transmit all-zero computed TCP checksum as all-ones; while they are certainly equivalent in two's complement arithmetics, but RFC 793 does not grant us to do this conversion (as opposed to RFC 768), and there may an implementation exist that computes checksums from scratch using the "shift-and-add-carry" algorithm to compute the two's complement sum on a non-two's-complement hardware, and compare the result with what stored in the checksum field. In this case, +0 and -0 will differ. To be LIBERAL, the implementation SHOULD verify checksums by computing the checksum using the value stored in the checksum field, and comparing the result with zero, as opposed to computing the checksum from scratch and comparing with the value stored in the checksum field. Cheers, -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010307171956.B36537>