Hello netbsders.  I'm running an aging netbsd-current kernel dated January
16, 1994 on several different machines, (some 386 and some 486).  I am
experiencing a very strange problem with the mount command.  
	When I give an nfs mount request on a netbsd client by name for a server
which is running SunOS 4.1.3 or NetBSD, the mount goes fine.  If I give the
same request for a server which is running Solaris 2.2, the mount fails and
the client says that the server is not responding.  Note that this only
happens if I give the server name on the mount command line.  If I give the
ip address of the server on the mount command line, the mount command
works.  Before you conclude that the resolver just isn't working for the
specified machine, let me continue.
	A run with tcpdump between client and server revealed that the packets 
for the nfs mount request were being sent out to the correct server at the
correct address.  The server responded happily enough to each request.  The
 problem seems to be that when a name is given on the mount command line
for a server running SunOS 5.2, the client (netbsd) sends out a request for
the fstatfs of the top directory on udp port 2.  When the reply comes
back, netbsd sends off an icmp: port 1023 is unreachable to the nfs server.
 This exchange continues indefinitely and, as it continues, fewer and fewer
network services work on the netbsd client.  Finally, telnet sessions are
impossible and it is impossible to get any rpc data through to the netbsd
machine.  It doesn't icmp, it just times out.
	The only difference I can detect between the Solaris machines and the
netbsd/SunOS4 machines is the fstatfs request port number.  On
NetBSD/SunOS4 machines, it seems to be set at around 7 or 8.  Likewise, if
I give the inet address of the Solaris 2 box it settles in at 7 or 8.  If I
give the name, however, it drops to 2 and the trouble begins.  

	Has anyone else seen this behavior and, if so, have they found a cure for it?
	What is the algorithm for deciding which port number to use?  
	I realize that this may be fixed in the current kernel, but since I haven't
seen the topic come up in this form on this list, and since I'm trying to
do some major development work on a relatively stable platform, I thought I
would ask.  If it is a known problem that has ben fixed, then I'll upgrade.

	Thanks for any light anyone can shed on this problem.
-Brian <buhrow@cats.ucsc.edu>

------------------------------------------------------------------------------