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>