Re: is NetBSD-4.x NFS Server locking support broken?

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 20-Sep-08, at 8:47 AM, Manuel Bouyer wrote:
> You says your OS X box is behind a NAT; I wonder is the NAT is  
> preventing
> the server to talk to the client's rpcbind or statd here.

I don't think basic RPC is a problem through the NAT.  Note that NFS  
over UDP does work fine through the NAT too, and IIRC all of NFS is  
RPC too.

Manual rpcinfo tests also show normal responses, though  I'm not sure  
about the version mismatch bit, however it does seem to happen  
identically with TCP and UDP, and more importantly it also happens  
identically from a NetBSD client system too (one that's directly on  
the same ethernet and in the same subnet).

13:46 [1617] $ /usr/sbin/rpcinfo -p once
   program vers proto   port
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100000    4     0    111  portmapper
    100000    3     0    111  portmapper
    100000    2     0    111  portmapper
    100005    1   udp   1021  mountd
    100005    3   udp   1021  mountd
    100005    1   tcp   1022  mountd
    100005    3   tcp   1022  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100001    1   udp  65495  rstatd
    100001    2   udp  65495  rstatd
    100001    3   udp  65495  rstatd
    100002    2   udp  65494  rusersd
    100002    3   udp  65494  rusersd
    100008    1   udp  65493  walld
    100011    1   udp  65492  rquotad
    100011    2   udp  65492  rquotad
    100024    1   udp    993  status
    100024    1   tcp   1010  status
    100021    0   udp    992  nlockmgr
    100021    1   udp    992  nlockmgr
    100021    3   udp    992  nlockmgr
    100021    4   udp    992  nlockmgr
    100021    0   tcp   1009  nlockmgr
    100021    1   tcp   1009  nlockmgr
    100021    3   tcp   1009  nlockmgr
    100021    4   tcp   1009  nlockmgr
13:47 [1618] $ /usr/sbin/rpcinfo -u once 100021
program 100021 version 0 ready and waiting
program 100021 version 1 ready and waiting
rpcinfo: RPC: Program/version mismatch; low version = 0, high version  
= 4
program 100021 version 2 is not available
program 100021 version 3 ready and waiting
program 100021 version 4 ready and waiting
ksh: exit code: 1
13:47 [1619] $ /usr/sbin/rpcinfo -t once 100021
program 100021 version 0 ready and waiting
program 100021 version 1 ready and waiting
rpcinfo: RPC: Program/version mismatch; low version = 0, high version  
= 4
program 100021 version 2 is not available
program 100021 version 3 ready and waiting
program 100021 version 4 ready and waiting
ksh: exit code: 1
13:47 [1620] $
13:48 [1622] $ uname -a
Darwin macweird.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep  3  
11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386


> Maybe using RPC over TCP for lockd/statd could help in this case.

How would one do that?  Especially since in this case the program  
making the requests is effectively the OSX kernel....  (and wouldn't  
using NFS over TCP, as I'm doing, do all RCP over TCP?)

> > Sep 19 17:10:17 once rpc.lockd: lock from macweird.local.8243:  
> > already locked, failed
>
> This is probably because the client sends the request multiple times.

Yeah, I think that's what I determined as well the last time I tried  
doing some network level tracing.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>

Attachment: PGP.sig
Description: This is a digitally signed message part