Date: Wed, 25 Mar 1998 15:23:08 -0500 (EST) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: freebsd-hackers@FreeBSD.ORG Subject: Re: ARP REQUEST question Message-ID: <Pine.SUN.3.91.980325151635.9569E-100000@terra> In-Reply-To: <199803251911.LAA12206@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Mar 1998, David Greenman wrote: > Switches should be checking the CRC on inbound packets and discarding > them if it is bad, so I don't see a problem. No problem if the crc on the inbound packet is bad. Discard it. Suppose there's a problem though between the 'inbound crc check' and the 'outbound crc generate' such that one bit in the packet is corrupted. Say, a pattern that results in a marginal component internal to the switch corrupting data, then the corrupt data is used to generate crc-32 on the outgoing side. Boom, corrupted packet, no indication. This can and does happen. Checksums have to be end-to-end. To paraphrase one vendor's manual: "To resolve this problem, turn on UDP checksums". (translation: we don't know what's going wrong. We can't help you fix it. But we can at least tell you that it DID go wrong). Most recent (humorous) example: Don Becker reports that he detected problems with gigabit ethernet cards via IP checksums. The problems occured (yikes!) on the destination machine, as the data was transferred from the card to main memory. No crc-32 error can catch that one, since it's already been checked on the card. Ouch. ron 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.SUN.3.91.980325151635.9569E-100000>