Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!hp4nl!phigate!nlgvax!geertj
From: geertj@nlgvax.UUCP (Geert Jan de Groot)
Newsgroups: comp.protocols.nfs
Subject: Re: PC-NFS problems on 386
Summary: Install rpc.pcnfsd on all machines that answer RARP requests!
Message-ID: <260@nlgvax.UUCP>
Date: 25 Jun 89 14:03:05 GMT
References: <8906121909.aa13452@ICS.UCI.EDU>
Reply-To: geertj@nlgvax.UUCP (Geert Jan de Groot)
Organization: Philips Research Geldrop
Lines: 82

In article <8906121909.aa13452@ICS.UCI.EDU> milne@ICS.UCI.EDU (Alastair Milne) writes:
>    On PC's with the i286 or i386, NET START RDR usually winds up reporting:
>
>	Cannot send broadcast packet: Unknown error
>	NFS028W : Unable to find a YP server for domain uci-ics.
>	net:  Unable to get hostname by ip addr (128.195.1.53)
>
>	(the ip addr reported is always correct for the host reporting it)
>
>    Now, the net nevertheless seems to run correctly (i.e. the operations we
>    try succeed); according to NFSCONF, the PC host picks up everything it's
>    supposed to by YP and RARP (host name, IP number, subnet mask, etc.).  


We have had the same trouble, and found a solution (at least, one that works
for us). This is what I did:

- The problem seemed to become less frequent when I explicitly set the
  netmask by hand:
	NET YPDOMAIN <domain>
	NET SUBNET 255.255.255.0
	NET START RDR

- The problem did not go away. Then, while looking with etherfind(1), 
  we found the reason: PC-NFS kinda hooks onto the system it receives
  a REVARP response from. That is, it expects it to be a YP server, with
  rpc.pcnfsd installed and a lot more.
  As an experiment, try to switch off all rarpd's on all machines except
  the YP master server (which hopefully has rpc.pcnfsd installed), then
  boot your PC a few times. The problem should disappear by then.

- To fix the problem, enter the PC's ethernet address only on the machines
  which run on the same YP domain as the PC. Also, install rpc.pcnfsd
  on all those machines. We have rarpd running only on our fileservers,
  and all fileservers have pcnfsd installed.

  When a new fileserver comes in (which happens frequently in the last 
  months :-), the PC users are the first to discover the new machines
  because they start getting the messages described above. Switching
  off rarpd until pcnfsd is installed fixes that.

 
>    [it] seems clear that YP is in fact succeeding in using the domain name 
>    we specify.

Usually, a race condition starts between the fileservers. If a server
with pcnfsd wins, all is OK, if not, error. This was OK until SUN4 servers
came in, which always won because they were much faster than SUN3's.

>    The ethernet card we use is the WD8003E.  Has anybody heard of this card's
>    having problems when used with a relatively high-speed CPU?  

We use them in 30 AT clones, and they work fine for us.

>       (before we put the /i3 on WD8003E.SYS, we were enormously frustrated in
>       trying to discover why the net refused to come up.  The /i3 was the
>       answer for almost every PC on the net.)

INT3 is used by the second serial I/O channel, if available.
For AT's, we use INT5, since nobody has a second parallell printer. 
I believe INT5 is used for the harddisk on a XT, which explains your
problems.
 
I hope this is of some help to anybody. I would like to receive a message if
it cleared your problems with PC-NFS.

BTW, does anybody know if PCNFS version 3.1 is out already? I was told
to expect it in june or july.

Good luck, 
Geert Jan


--8<--nip-nip---------------------------------------------------------------

Geert Jan de Groot,			Email: geertj@nlgvax.pcg.philips.nl
Philips Research Laboratories,		       ..!mcvax!nlgvax!geertj
Project Centre Geldrop,			Ham: PE1HZG
Building XP, Room 4,
Willem Alexanderlaan 7B,		"MS-DOS is just a bootstrap" - me
5664 AN Geldrop, The Netherlands.
phone: +31 40 892204			[Standard disclaimers apply]