Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!orion.oac.uci.edu!ucivax!gateway
From: milne@ICS.UCI.EDU (Alastair Milne)
Newsgroups: comp.protocols.nfs
Subject: RARP failure on subnets?
Message-ID: <9104122345.aa20048@ICS.UCI.EDU>
Date: 13 Apr 91 06:47:57 GMT
Lines: 44


   This is something we found a long time ago with PC-NFS 3.0.1 .
   I have in fact described it a couple of times on the net already,
   in answer to other posts, but it never occurred to me to see if
   Geoff could say something about it.

   We have a net of about 10 PC's, all on a thinnet connected to a
   Sun 3 or 4 in the next building over.  This thinnet is a subnet,
   and the Sun of course is the gateway to the backbone of the department's
   net.  When we originally installed (Geoff, telnet is scarcely letting
   me get 20 characters typed -- sometimes hardly 5 -- without freezing in its
   tracks for several seconds) we wanted to use RARP.  Very attractive,
   after all -- don't even need a simple hosts table on the individual PC.

   But it kept failing.  The boot would often hang at the net start, and
   nothing would happen.  Our network administrator did some investigating,
   and determined that the broadcast packet RARP was sending was asking not
   "are you a YP server?" but "who is your YP server?".  Whatever it was told
   it would try to assign as the YP server for the booting PC.

   Now, there were then a couple of Suns that could provide YP service within
   the subnet, but many more that could not.  But RARP didn't seem to be
   telling the difference.  So it often gave the client PC a YP server the PC
   couldn't use.

   After we stopped using RARP, these problems disappeared; instead, the PC
   makes it through that phase with a minimal 'host' table, then turns on YP
   and grabs a server.  Not bad, but I still wouldn't mind having a fully
   working RARP.  Among other things, our site had at least 2 changes of
   IP addresses, and if our network services hadn't told me about them,
   I need never have known.  RARP made them that smooth.


   So my question to Geoff: a) is our diagnosis correct?  Is this how RARP is
   working?  and b) are its problems being fixed?  I suspect the latter is
   rather slow, because I've just seen a user's reaction to PC-NFS 3.5 on the
   net, and it appears RARP is still not working properly.


   Thanks for whatever you can tell me.

   Alastair Milne,
   Educational Technology Center,
   UC Irvine