From owner-freebsd-hackers Thu Mar 26 13:02:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24214 for freebsd-hackers-outgoing; Thu, 26 Mar 1998 13:02:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sparks.net (exim@[208.221.75.8]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA23785 for ; Thu, 26 Mar 1998 13:01:34 -0800 (PST) (envelope-from david@sparks.net) Received: from david by sparks.net with smtp (Exim 1.62 #5) id 0yIJXE-0003yI-00; Thu, 26 Mar 1998 15:46:00 -0500 Date: Thu, 26 Mar 1998 15:45:59 -0500 (EST) From: To: "Ron G. Minnich" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ARP REQUEST question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 25 Mar 1998, Ron G. Minnich wrote: > 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. What meaning does an arp entry have for an interface which is not on a local interface? And if it *is* on a local interface, the level two error checking should handle it. > 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. Uhmm, using software to determine whether the hardware which is running on it is functioning properly sounds generally self-defeating. --- David ---------------------------------------------------------------------------- It's *amazing* what one can accomplish when one doesn't know what one can't do! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message