From owner-freebsd-hackers Wed Mar 25 07:44:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26884 for freebsd-hackers-outgoing; Wed, 25 Mar 1998 07:44:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spiv.fnal.gov (spiv.fnal.gov [131.225.124.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26875 for ; Wed, 25 Mar 1998 07:44:11 -0800 (PST) (envelope-from neswold@fnal.gov) Received: from localhost (neswold@localhost) by spiv.fnal.gov (8.8.5/8.8.5) with SMTP id JAA24310; Wed, 25 Mar 1998 09:46:10 -0600 (CST) X-Authentication-Warning: spiv.fnal.gov: neswold owned process doing -bs Date: Wed, 25 Mar 1998 09:46:10 -0600 (CST) From: "Richard M. Neswold" Reply-To: neswold@fnal.gov To: pratap singh cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ARP REQUEST question In-Reply-To: <19980325145544.10507.qmail@hotmail.com> Message-ID: X-Spambot-Food: abuse@localhost postmaster@localhost abuse@fbi.gov 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, pratap singh wrote: > I perfectly know about the CRC carried in the ethernet frames. But if that > is the case the higher layer protocols still do the checksum like IP. the > reasons that I feel for not having the checksum in the ARP frame are: > 1> IP packets get routed and can be seen to ascend and descend protocol > stacks till they reach their destination. So even if the layer 2 > (ethernet) checksum is right, they may get corrupted during the ascend and > descend. And if the checksum is not provided by the IP itself, this error > could go unnoticed. If they get corrupted during the ascend or descend, you have a software bug in your TCP/IP stack. The reason IP adds its own checksum is because it can't make an assumption about what interface is being used. Although ethernet can reject a packet with a bad CRC, an RS-232C connection doesn't have this safeguard (unless you're using error correcting modems.) > 2> However same is not the case with ARP which in the protocol stack sat > with the hardware independent part of the Ethernet driver or any other > layer 2 driver (historically) and so the traversal of the protocol stack > was not necessary. And the local significance made the CRC just enough for > detecting errors. But what in case of network stacks of today where the > ARP is seen sitting together with IP or at the same level of IP. Someone > Please correct me If I am wrong. ARP is only used on LANs. To communicate on a LAN, you need a network card which can be ethernet, token ring, arcnet, etc. Each of these technologies has a way of validating incoming packets, so an ARP CRC is redundant. General IP packets can leave the local network through routers which can be RS-232C, radio broadcasts, satellite links, etc. which may not, themselves, have a way to detect transmission errors. Now it's my turn to be corrected if I'm wrong... Rich ------------------------------------------------------------------------ Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message