[Bug 229601] Re: nfs-kernel-server connects to local statd with wrong source ip

[Ernst Kloppenburg]

the problem seems to be gone

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/229601

Title:
  nfs-kernel-server connects to local statd with wrong source ip

Status in “nfs-utils” package in Ubuntu:
  Incomplete

Bug description:
  With nfs-kernel-server and nfs-utils in hardy i experience the
  following problem which looks to me like a bug. The problem was
  already present in gutsy, but not in feisty.

  - nfs-common assumes that connects to rpc.statd can only come from the
  ip address 127.0.0.1 (localhost). This is due to the configure option
  '--enable-secure-statd' in debian/rules.

  - but actually, the local nfs-kernel-server connects to the local
  rpc.statd with source ip equal to the ip address of the real ethernet
  interface, which leads to error messages in the system log, see below.

  In my setup, the NFS server has host name 'machine4' and ip address 192.168.0.4. 
  The NFS client has host name 'machine5' and ip address 192.168.0.5.
  Both are running ubuntu hardy. 
  /etc/hosts has these lines on the server:
  127.0.0.1 localhost
  192.168.0.4 machine4 apt-proxy

  
  These are the error messages in the server log:
  May  5 21:51:32 machine4 rpc.statd[10442]: Call to statd from non-local host 192.168.0.4
  May  5 21:51:32 machine4 rpc.statd[10442]: STAT_FAIL to machine4 for SM_MON of 192.168.0.5

  The first of the two lines shows the problem that the connect from the
  local nfs server to the local rpc.statd is not accepted as a local
  connect. This always happens when some application on machine5 tries
  to access (or lock?) files that are mounted from machine4.

  One may ask the question, was the connect really a local connect. This question was anwered by running tcpdump. First I found out the right port numbers:
  root at machine4:~# rpcinfo -p
     program vers proto   port
      100000    2   tcp    111  portmapper
      100000    2   udp    111  portmapper
      100024    1   udp  42443  status
      100024    1   tcp  32947  status

  Then I ran 'tcpdump -i lo udp port 42443 or tcp port 32947' which
  results in the following output which clearly shows the local origin
  of the connect:

  21:51:32.105295 IP machine4.747 > localhost.42443: UDP, length 40

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/229601/+subscriptions