Path: utzoo!attcan!uunet!mcvax!hp4nl!philmds!nlgvax!geertj From: geertj@nlgvax.UUCP (Geert Jan de Groot) Newsgroups: comp.protocols.nfs Subject: Re: Problems with PC-NFS Summary: A (_dirty_) workaround Message-ID: <200@nlgvax.UUCP> Date: 23 Jan 89 21:52:34 GMT References: <3650@phri.UUCP> Reply-To: geertj@nlgvax.UUCP (Geert Jan de Groot) Organization: Philips Research Geldrop Lines: 63 In article <3650@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > We've recently gotten PC-NFS runnng on a PC-AT and have noticed a >couple of problems. One is that when I run NFSRUN, when it gets up to the >"NET START RDR", it hangs for a few seconds and then I get: > > Cannot send broadcast packet: unknown error > NFS028W: unable to find a YP server for domain PHRI > net: unable to get hostname by IP addr (128.122.136.101) > > The odd thing is that it then procedes to run through the rest of >the NFSRUN script and when it's done (almost) everything appears to work >just fine. YP is obviously working since it's able to resolve hostnames >without any problem (and without a local hosts file). NFS, Telnet, and NET >PRINT all work too. I have had the same trouble at our site. Even worse, it sometimes really couldn't find a YP server and didn't start up properly. A quick overview: we have a number of sun3 fileservers running SUNOS3.5, a sun4 fileserver running SUNOS3.2, an ULTRIX vax, and a sun386 roadrunner. Anyway, an experiment with etherfind shows what happens: the pc sends a RARP broadcast, and then one of the servers (probably more) respond. Then the PC sends some UDP packets to the same machine it got the first RARP response from. It apperently clamps itself to that machine asking for more info. Now, if the responding machine was one of the sun3 machines, all works well. However, if one of the other architectures is faster, I got the same messages you did. Apperently, something botches with the other architectures. Depending on the load of these machines, you get an unstable situation: if the sun3 fileservers are busy, no PC is able to hook into the network, because the other machines are less loaded, are faster and win the race. As temporary fix, we switched off all rarp daemons, except for the sun3 machines. This way, a sun3 fileserver always wins. Since then, everything runs smoothly. This of course is only a temporary fix. (I *hope* PCNFS will work with SUNOS 4.0 on the sun3 machines !). Setting the YP server explicitly does not help, because YP will need the ARP data, and loses there. I have reported the problem to SUN but have had no answer yet. BTW: does anybody have had any luck with the DOS APPEND command and PCNFS? APPEND doesn't work if either the current drive or the append drive is an NFS drive. If they are both local (winchester of floppy), APPEND works. Anybody any ideas? Geert Jan -.-.- --... ...-- -.. . .--. . .---- .... --.. --. .-.-. Geert Jan de Groot, Email: geertj@nlgvax.pcg.philips.nl Philips Research Laboratories, Packet: PE1HZG @ PI8ZAA Project Centre Geldrop, AMPRNET: [44.137.24.3] Building XR, Room 15, Willem Alexanderlaan 7B, "When in doubt, 5664 AN Geldrop, The Netherlands. tune for minimum smoke phone: +31 40 892204 and then consult a reference" [Standard disclaimers apply] -(Found in a manual)