Date: Wed, 25 Mar 1998 13:16:43 -0500 (EST) From: "David E. Cross" <dec@phoenix.its.rpi.edu> To: "Ron G. Minnich" <rminnich@Sarnoff.COM> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ARP REQUEST question Message-ID: <Pine.BSF.3.96.980325130952.17889B-100000@phoenix.its.rpi.edu> In-Reply-To: <Pine.SUN.3.91.980325124900.9569B-100000@terra>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Mar 1998, Ron G. Minnich wrote: > On Wed, 25 Mar 1998, Niall Smart wrote: > > The "ascent" and "descent" through the protocol stacks, e.g., the > > demultiplexing of an ethernet packet to IP to TCP, is done entirely in > > software (or "reliable" hardware). Any corruption here is due to bugs > > in the networking code which should be eliminated. The reason IP has > > checksum field is that it cannot rely on the underlying network, be it > > ethernet, token ring or a VPN, to reliably deliver the data. That is > > the raison d'etre of TCP/IP. > > I don't think that is the whole story. Checksums or CRCs should be > end-to-end. We've learned that the hard way often enough. Ethernet CRCs > are not end-to-end. It's not an issue of reliable delivery. It's an issue > of being able to detect data corruption. That's why udp checksums are > always left turned on for NFS in so many sites. > > Niall is right that corruption "should not" happen. The real question is > whether it does (and it does). So you need some sort of end-to-end > checking. > > The first time I saw this was a router with an undetected memory error. > Of course, it was in high memory, and of course, only occasionally did > packets get tromped, since high memory was only used heavily under heavy > offered load. Turning UDP checksums on for NFS would catch the problem, > when there was enough load. > I see what you are saying with corrupted packets being introduced by a flaky ethernet card, but keep in mind that true 'end to end' detection and reliability is not possible, if you have a bad memory circut, in the place wher you are building the packet in the kernel, you are going to get a bogus packet no matter what, since you will compute the checksum on the corrupted packet. It is also of note how laughable the Internet checksums are, they are 16 bit modulo 2^16 checksums, they are NOT CRCs... a simple byte swap can confuse them, or inserting 0s into the stream. They are not 'reliable' in any real sense of the word anyway. I do not have the statistics in front of me, but it is many orders of magnitude more like for something to slip through a simple checksum, than it is for CRC. Finally, if you have an ethernet card that munging packets (especially ARP packets), I doubt the netowkr on that computer will work at all; very directly pointing the finger that something is wrong. PS: Is anyone here in a position to rewrite the ARP RFC? -- David Cross UNIX Systems Administrator GE Corporate R&D 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?Pine.BSF.3.96.980325130952.17889B-100000>