From adnan@icd.ab.com Mon Jul 13 15:25:56 1992 From: adnan@icd.ab.com (Adnan C. Yaqub) Newsgroups: comp.unix.sysv386,comp.protocols.nfs Subject: ESIX 4.0.3 - Sun 4 NFS Problem *** SOLUTION *** Date: 13 Jul 92 14:08:37 GMT Followup-To: comp.unix.sysv386 Organization: Allen-Bradley Inc., Highland Heights, OH, USA. Nntp-Posting-Host: redstart.icd.ab.com Recently I posted an article detailing a problem I was having with importing a disk from a Sun 4 to an ESIX system (4.0.3) using NFS. Basically I was getting the error message on my ESIX system nfs mount: munin:/fs7: server not responding: RPC: Program not registered every time I tried to mount the remote disk. I got a response from Mr. Badura which detailed a bug in USL's code. (I have enclosed his response.) When I removed the resolver libraries from netconfig (which of course means I can't use the nameserver) NFS started working. I contacted ESIX, and I am not impressed with their technical support. (It is free, so I guess you get what you pay for.) When I first mentioned this problem, they claimed that they had tested ESIX NFS with Suns. (Maybe they did, but without the nameserver.) Their ideas of solutions to the problem involved reloading the software and sending out new disks in case mine were "corrupted". (When sending the disks, they first sent them to Oklahoma instead of Ohio, and then they sent the wrong disks [4.0.4]. I still haven't received the correct ones.) When I informed them about the bug Mr. Badura pointed out, their response seemed to be, "What do you want us to do about it?" When I suggested that they at least look into the problem they said that their networking support was done in Singapore. Finally they agreed to receive a FAX from me (their email has been broken for 3 months!) and possibly send it on to Singapore. I am now waiting for my 4.0.4 upgrade. (I need the nameserver and NFS at the same time.) Here is Mr. Badura's response: Return-Path: From: Christoph Badura Subject: Re: ESIX to SUN4 NFS Problem To: "Adnan C. Yaqub" Date: Thu, 9 Jul 1992 23:05:35 +0200 Reply-To: bad@generics.ka.sub.org In-Reply-To: <9207091212.AA12751@odin.icd.ab.com>; from "Adnan C. Yaqub" at Jul 9, 92 2:12 pm X-Mailer: ELM [version 2.2 PL13] > Yes, I am. Also, I can telnet to munin from the Esix system so I > think the name resolution is working. That could be the problem. The stock USL resolver library suffers from serious confusion about the byte order in the socketaddr_in structure. This bug is acknowledge by USL for the 4.0.4 release. Try removing the references to /usr/lib/resolv.so from /etc/netconfig (I believe thats the name) and reboot your system. If this works, complain to ESIX. If they don't believe you, you can refer them to me (note the Reply-To: at my work address), I can quote them chapter and verse in the source. > Chen> Due to the portmapper do not understand rpcbind, therefor, > Chen> R4 system can be both client or server to non-R4 NFS system. > Chen> But non-R4 system can only be a client to R4 NFS. > Chen> > Chen> This problem will be resolve when sun start shipping SunOS5.0 (SVR4). > > If this is correct, I need to upgrade my Suns at a later date. I find > it somewhat difficult to believe that SVR4 won't NFS with Suns. I'm afraid Mr. Chen is mostly incorrect. The portmapper and rpcbind should understand each other perfectly. I had no problem using PC-NFS 4.0 with the damaged resolver librarys. The following explains the effects Mr. Chen is seeing perfectly and doesn't require a rpc-protocol mismatch. I haven't verified this, because I fixed the resolver library. Rpcbind makes a call to netdir_getbyname, which tries each name-to-address resolution module mentioned in /etc/netconfig for the specified protocol family until it gets an answer. Now the call by rpcbind probably looks roughly like: netdir_getbyname(&result, `uname -n`, "rpcbind", "udp"); Since the local hostname return by "uname -n' is likely to be found in /etc/hosts, the /usr/lib/tcpip.so name resolution module supplies the answer. tcpip.so doesn't suffer from the byte order confusion and rpcbind binds to port htons(111). This is why the suns are able to contact the rpcbind aka portmapper on R4. The local rpc-programs obtain in some way their ports an register that with rpcbind; here byte order is no issue, since rpcbind just advertises what it's been told, with no byte order mangling. When you try to mount from the suns, the /usr/lib/nfs/mount probably goes through the nameserver in the call to netdir_getbyname, and this is where the port number gets mangled. Basically it tries to find the remote rpcbind aka portmapper at port ntohs(htons(111)) which is 111 in little endian byte order when it should be big endian. If you're interested, you should be able to verify this with different configurations of /etc/hosts and /etc/netconfig. -- Christoph Badura --- bad@flatlin.ka.sub.org UNIX is a trademark of LEBEDA & Co, Ges.m.b.H, Vienna, Austria -- Adnan Yaqub (adnan@icd.ab.com) Allen-Bradley Company, Inc., 747 Alpha Drive, Highland Hts., OH 44143, USA Phone: +1 216 646 4670 FAX: +1 216 646 4484