"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)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
wow regex humor... I'm a geek
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
