Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!topaz.rutgers.edu!hedrick
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Newsgroups: comp.sys.celerity
Subject: problem with RARP in newest celerity release
Message-ID: <15814@topaz.rutgers.edu>
Date: Thu, 22-Oct-87 02:33:15 EDT
Article-I.D.: topaz.15814
Posted: Thu Oct 22 02:33:15 1987
Date-Received: Sat, 24-Oct-87 16:49:06 EDT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 43


We have found a fairly serious problem with 3.4.88.  It attempts to
implement RARP.  This is a facility by which diskless machines can
find out their Internet address when they are booting.  RARP is used
by Suns as part of their boot process.  It is also used by our network
gateways when they boot.  On the Sun, at least in SunOS 3.2, RARP is
implemented as a program.  This program reads a file, /etc/ethers,
which contains a list of hosts for which the machine is prepared to
respond to RARP requests, and their Internet and Ethernet addresses.
This approach works fine (though the implementation has a problem that
causes it not to work for us; but that's another story).  Celerity
chose to implement RARP in the kernel.  Instead of reading
/etc/ethers, the kernel RARP support uses the kernel's ARP table.
From external behavior, it looks like RARP takes the Ethernet address,
looks for an entry in the ARP table with this Ethernet address, and
returns its Internet address.  Unfortunately, the ARP table is not
intended to provide mappings in this direction.  It is designed to go
from Internet address to Ethernet address.  If you are using proxy
ARP, using the table in reverse will result in bad information.

For example, our gateways use proxy ARP.  This is a technique by which
gateways respond to ARP requests for hosts on the other side of the
gateway.  Thus there are typically several entries in the ARP table
containing the Ethernet address of the gateway.  If we reboot the
gateway, when it is coming up, it issues an RARP request.  The
Celerities will respond to this request by giving the Internet address
of some system for which the gateway had been forwarding packets.
Thus the gateway comes up with a completely bogus Internet address.
In my opinion, it is a bad practice to do RARP based on the ARP table.
Indeed it is probably a bad idea to do RARP at all unless it is
requested.  I think the approach of a user-mode utility program is a
better one.  I have reported this bug to Celerity.  I'm posting it
here because it can create symptoms elsewhere on the network that are
nearly impossible to trace.  Now you are warned...

The other disadvantage of the using the ARP table is that when a whole
room of machines is coming up after a power failure, all the ARP
tables will start out empty.  In order to handle power failures, any
machine that acts as an RARP server must not depend upon the table
being dynamically built.  Thus rc.local would have to have calls to
/etc/arp to add the appropriate entries statically.  So this approach
does not get around the need for static tables.  I think /etc/ethers
is a better place for this information...