From owner-freebsd-hackers Wed Mar 25 12:35:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA28066 for freebsd-hackers-outgoing; Wed, 25 Mar 1998 12:35:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA28052 for ; Wed, 25 Mar 1998 12:35:44 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id MAA13083; Wed, 25 Mar 1998 12:35:34 -0800 (PST) Message-Id: <199803252035.MAA13083@implode.root.com> To: "Ron G. Minnich" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ARP REQUEST question In-reply-to: Your message of "Wed, 25 Mar 1998 15:23:08 EST." From: David Greenman Reply-To: dg@root.com Date: Wed, 25 Mar 1998 12:35:34 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >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. This assumes that the CRC is regenerated; I can't think of any reason why this would need to be done inside of an ethernet switch - you already have the (checked) CRC, so why would you need to regenerate it? From your own scenario above, it's obvious why it would be undesirable to do so. Anyway, all this has very little to do with FreeBSD so I'm wondering why this is being discussed here. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message