From owner-freebsd-hackers Wed Jun 6 2:57:55 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from newsguy.com (perry.pathlink.com [209.155.233.33]) by hub.freebsd.org (Postfix) with ESMTP id C4BDE37B401 for ; Wed, 6 Jun 2001 02:57:49 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (ppp045-bsace7001.telebrasilia.net.br [200.181.80.45]) by newsguy.com (8.11.0/8.9.1) with ESMTP id f569vIq08510; Wed, 6 Jun 2001 02:57:19 -0700 (PDT) Message-ID: <3B1DFEAF.927E1DC3@newsguy.com> Date: Wed, 06 Jun 2001 06:58:07 -0300 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en,pt-BR,pt,en-GB,en-US,ja MIME-Version: 1.0 To: "Louis A. Mamakos" Cc: Giorgos Keramidas , Bob Willcox , Jesper Skriver , hackers list Subject: Re: How to disable software TCP checksumming? References: <20010529144114.I19771@luke.immure.com> <20010529221107.C49875@skriver.dk> <20010529155212.M19771@luke.immure.com> <20010530045200.A1031@hades.hell.gr> <3B1CACDA.96599BD5@newsguy.com> <200106051422.f55EM4n78505@whizzo.transsys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Louis A. Mamakos" wrote: > > > > > It seems to me to be kind of moot to check the same value twice, unless > > you suspect hardware problems. Aren't you talking about two different > > checks over the same data instead of checksum off-loading? > > Suspect hardware problem? Of course you should! That's why memory > systems have parity or ECC, and I/O buses are similarlly protected. At > least on real computers. > > The link-level CRC only protects the data as it goes over the link ^^^^^^^^^^ After reading the rest of his messages, I'm not so sure, but I would think he was talking about _transport_ level check sum, and verifying that with hardward (NIC) instead of software (IP stack). > between the link-level hardware which generates the CRC and the box > on the other end that receives it. It does not protect the data > end-to-end, so if it's gets corrupted whilst sitting in memory in > an intermediate node, you won't detect that. > > Why would it get corrupted? > > 1. Software. Random unrelated other software does a random store in > the buffer containing your packet sitting in memory. Fancy device drivers > that do scatter-gather I/O gets it wrong every now and then and points > off into space. mbuf cluster which should be treated as read-only isn't, > and some other code hoses it. (See PR kern/27782 at > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27782 for an example of this.) > > 2. Hardware. I found broken UNIBUS hardware 15 or 20 years ago this > way. I had some broken hardware which took frame relay frames on > a HSSI interface and turned them into AAL5 ATM cells that would get > the cell reassembly wrong if you pushed too hard. Or just plain > broken memory that results in packet corruption. > > I've personally experienced all these problems. Maybe I'm just > unluckly. One common thread of my experiences is being close to the > bleeding edge of technology where stuff isn't as mature as many people > are used to. > > This end-to-end issue is not a theoretical consideration. While the > 1's complement internet checksum isn't that strong, it does detect a > bunch of bug-like behavior like this. > > Louis Mamakos -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.secret.bsdconspiracy.net wow regex humor... I'm a geek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message