Date: Wed, 07 Mar 2001 09:58:32 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Ruslan Ermilov <ru@FreeBSD.ORG> 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: <200103071458.f27EwWa99960@whizzo.transsys.com> In-Reply-To: Your message of "Wed, 07 Mar 2001 16:48:22 %2B0200." <20010307164822.E97252@sunbay.com> References: <20001116120936.A45755@sunbay.com> <20001116091954.A19895@prism.flugsvamp.com> <20010307123156.A19829@sunbay.com> <200103071440.f27EeYa99809@whizzo.transsys.com> <20010307164822.E97252@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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?200103071458.f27EwWa99960>