Date: Wed, 06 Jun 2001 06:58:07 -0300 From: "Daniel C. Sobral" <dcs@newsguy.com> To: "Louis A. Mamakos" <louie@TransSys.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: <3B1DFEAF.927E1DC3@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> <200106051422.f55EM4n78505@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B1DFEAF.927E1DC3>