Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Mar 1998 13:54:42 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        "Ron G. Minnich" <rminnich@Sarnoff.COM>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: ARP REQUEST question
Message-ID:  <199803252154.NAA07247@salsa.gv.tsc.tdk.com>
In-Reply-To: "Ron G. Minnich" <rminnich@Sarnoff.COM> "Re: ARP REQUEST question" (Mar 25,  3:23pm)

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 25,  3:23pm, "Ron G. Minnich" wrote:
} Subject: Re: ARP REQUEST question
} 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. 

Switches and bridges should not regenerate the CRC on outbound packets.
They should just pass the incoming CRC through.

Routers must regenerate the CRC because they substitute their own
MAC address in the outgoing source address field and substitute the
MAC address of the next hop device in the outgoing destination address
field.  This isn't a problem for ARP, though, because routers don't
propagate ARP.

} Checksums have to be end-to-end. 

Yes.

} 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.

And you lose the ability to check this if your card does the checksums
in hardware.

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?199803252154.NAA07247>