Date: Tue, 05 Jun 2001 10:22:04 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Giorgos Keramidas <keramidi@otenet.gr>, Bob Willcox <bob@immure.com>, Jesper Skriver <jesper@skriver.dk>, hackers list <freebsd-hackers@FreeBSD.ORG> Subject: Re: How to disable software TCP checksumming? Message-ID: <200106051422.f55EM4n78505@whizzo.transsys.com> In-Reply-To: Your message of "Tue, 05 Jun 2001 06:56:42 -0300." <3B1CACDA.96599BD5@newsguy.com> References: <20010529144114.I19771@luke.immure.com> <20010529221107.C49875@skriver.dk> <20010529155212.M19771@luke.immure.com> <20010530045200.A1031@hades.hell.gr> <3B1CACDA.96599BD5@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Giorgos Keramidas wrote: > > > > There are good reasons why checksumming in upper layers should not be disabled > > even if some lower layer does checksumming of its own. I recall reading some > > good points on this one at "TCP/IP Illustrated, Volume I" from (now late) > > Richard W. Stevens. > > 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 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106051422.f55EM4n78505>