rpcbind behavior on Fedora 7

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

Hi Steve-

I was trying out the mount.nfs test case for another bug (see below). 
The test case didn't work against a Fedora 7 server.  Trying to mount 
with UDP against a specific port just hangs.  So I tried an rpcinfo 
against it to see what the current rocbind configuration was.

 > [root@picasso ~]# rpcinfo ingres
 >    program version netid     address                service    owner
 >     100000    4    tcp6      ::.0.111               portmapper superuser
 >     100000    3    tcp6      ::.0.111               portmapper superuser
 >     100000    2    tcp6      ::.0.111               portmapper superuser
 >     100000    4    udp6      ::.0.111               portmapper superuser
 >     100000    3    udp6      ::.0.111               portmapper superuser
 >     100000    2    udp6      ::.0.111               portmapper superuser
 >     100000    4    local     /v                     portmapper superuser
 >     100000    3    local     /v                     portmapper superuser
 >     100000    2    local     /v                     portmapper superuser
 >     100024    1    udp6      ::.2.222               status     unknown
 >     100024    1    tcp6      ::.2.225               status     unknown
 >     100021    1    tcp6      ::.170.233             nlockmgr   unknown
 >     100021    3    tcp6      ::.170.233             nlockmgr   unknown
 >     100021    4    tcp6      ::.170.233             nlockmgr   unknown
 >     100011    1    udp6      ::.3.158               rquotad    unknown
 >     100011    2    udp6      ::.3.158               rquotad    unknown
 >     100011    1    tcp6      ::.3.161               rquotad    unknown
 >     100011    2    tcp6      ::.3.161               rquotad    unknown
 >     100021    1    udp6      ::.128.0               nlockmgr   unknown
 >     100021    3    udp6      ::.128.0               nlockmgr   unknown
 >     100021    4    udp6      ::.128.0               nlockmgr   unknown
 >     100003    2    udp6      ::.8.1                 nfs        unknown
 >     100003    3    udp6      ::.8.1                 nfs        unknown
 >     100003    4    udp6      ::.8.1                 nfs        unknown
 >     100003    2    tcp6      ::.8.1                 nfs        unknown
 >     100003    3    tcp6      ::.8.1                 nfs        unknown
 >     100003    4    tcp6      ::.8.1                 nfs        unknown
 >     100005    1    udp6      ::.2.135               mountd     unknown
 >     100005    1    tcp6      ::.2.138               mountd     unknown
 >     100005    2    udp6      ::.2.135               mountd     unknown
 >     100005    2    tcp6      ::.2.138               mountd     unknown
 >     100005    3    udp6      ::.2.135               mountd     unknown
 >     100005    3    tcp6      ::.2.138               mountd     unknown
 > [root@picasso ~]#

Um.  Ok, where are the IPv4 entries?

I've now completely shut off IPv6 initialization and autoconfiguration 
on the only network interface on the system and rebooted several times 
(I wasn't using the IPv6 networking stuff yet anyway).  I still get *no* 
udp4 or tcp4 entries in the rpcbind database.  The NFS service on this 
system is all IPv4 (it's a Linux NFS server).

How are these getting registered?

Steinar H. Gunderson wrote:
> On Mon, Jul 23, 2007 at 06:13:42PM -0400, Chuck Lever wrote:
>> It would help if we could take a look at a clean network trace of the bad 
>> and the good mount operations.
> 
> It was quite simple to test this myself. I started the kernel server on a
> machine, then shut down portmap. First I did:
> 
>   fugl:~> sudo mount -t nfs -o port=2049,mountport=901,nfsvers=3 192.168.0.101:/ /mnt
>   mount: mount to NFS server '192.168.0.101' failed: System Error: Connection refused.
> 
> The dump is attached as "default.dump". Then I did
> 
>   fugl:~> sudo mount -t nfs -o port=2049,mountport=901,nfsvers=3,udp 192.168.0.101:/ /mnt 
> 
> which is attached as "udp.dump".
> 
> Note that in default.dump, UDP is simply never tried at all. I believe that
> to be a bug.
> 
> /* Steinar */

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs