Random UDP port assignment for rpc.statd

Random UDP port assignment for rpc.statd

[Haakon Riiser]

Why isn't it possible to specify all of statd's listening ports
using the -p flag?  It works for the TCP port and one of the
UDP ports, but there is always one more listening UDP port that
is randomly assigned.  I googled around for information on this
problem, and came up with this Debian bug report:

  http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg11985.html

The thread ends with "I think we may have a real bug", but this
was reported in 1.0.6, and the problem still persists in 1.0.7,
so I was wondering if this isn't a bug after all.

Btw, there's also a similar problem with nfsd:  In addition to
the standard listening port at 2049, it always opens a random
port in the high port range (32000-32768 or something like that).

In case it matters:  I'm using Linux 2.6.10 and Slackware 10.1.

-- 
 Haakon


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Trond Myklebust]

su den 20.02.2005 Klokka 12:13 (+0100) skreiv Haakon Riiser:
> Why isn't it possible to specify all of statd's listening ports
> using the -p flag?  It works for the TCP port and one of the
> UDP ports, but there is always one more listening UDP port that
> is randomly assigned.  I googled around for information on this
> problem, and came up with this Debian bug report:
> 
>   http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg11985.html
> 
> The thread ends with "I think we may have a real bug", but this
> was reported in 1.0.6, and the problem still persists in 1.0.7,
> so I was wondering if this isn't a bug after all.

rpc.statd needs some ports for communication with the portmapper and the
lockd manager on the loopback net, and this is probably what you are
seeing. There should be nothing that needs to be allowed firewall
access, though.

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Haakon Riiser]

[Trond Myklebust]

> su den 20.02.2005 Klokka 12:13 (+0100) skreiv Haakon Riiser:

>> Why isn't it possible to specify all of statd's listening
>> ports using the -p flag?  It works for the TCP port and one
>> of the UDP ports, but there is always one more listening UDP
>> port that is randomly assigned.  [...]

> rpc.statd needs some ports for communication with the portmapper
> and the lockd manager on the loopback net, and this is probably
> what you are seeing. There should be nothing that needs to be
> allowed firewall access, though.

Actually, I wanted to /block/ this port in the firewall, not open
for external access.  My firewall allows everything by default, and
has rules to block ports that shouldn't be visible to the world.
Should I be concerned about this port being unblocked?

-- 
 Haakon


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Trond Myklebust]

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

su den 20.02.2005 Klokka 15:10 (+0100) skreiv Haakon Riiser:
> > rpc.statd needs some ports for communication with the portmapper
> > and the lockd manager on the loopback net, and this is probably
> > what you are seeing. There should be nothing that needs to be
> > allowed firewall access, though.
> 
> Actually, I wanted to /block/ this port in the firewall, not open
> for external access.  My firewall allows everything by default, and
> has rules to block ports that shouldn't be visible to the world.
> Should I be concerned about this port being unblocked?

The ports for portmapper registration are destroyed after they are used.
The only port that is of worry is the one used for outgoing
communications (controlled by the "-o" option).

.... and of course, that control mechanism appears to be borken...

See if the attached patch doesn't fix things so that your 3rd rpc.statd
port stays on the port specified by "-o"...

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>

[-- Attachment #2: nfs-utils-1.0.7-fix_outgoing_port.dif --]
[-- Type: text/plain, Size: 1300 bytes --]

 Ehem...
  1) sin.sin_port is supposed to be in network order.
  2) bindresvport() is used to automatically choose the port for you.
     if you want to set the port yourself, use bind()
---
 rmtcall.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

Index: nfs-utils/utils/statd/rmtcall.c
===================================================================
--- nfs-utils.orig/utils/statd/rmtcall.c
+++ nfs-utils/utils/statd/rmtcall.c
@@ -65,7 +65,7 @@ statd_get_socket(int port)
 
 	memset(&sin, 0, sizeof(sin));
 	sin.sin_family = AF_INET;
-	sin.sin_port = port;
+	sin.sin_addr.s_addr = INADDR_ANY;
 	/*
 	 * If a local hostname is given (-n option to statd), bind to the address
 	 * specified. This is required to support clients that ignore the mon_name in
@@ -76,7 +76,15 @@ statd_get_socket(int port)
 		if (hp)
 			sin.sin_addr = *(struct in_addr *) hp->h_addr;
 	}
-	if (bindresvport(sockfd, &sin) < 0) {
+	if (port != 0) {
+		sin.sin_port = htons(port);
+		if (bind(sockfd, &sin, sizeof(sin)) < 0) {
+			note(N_CRIT, "failed to bind to outgoing port, %d\n"
+					"falling back to randomly chosen port\n", port);
+			port = 0;
+		}
+	}
+	if (port == 0 && bindresvport(sockfd, &sin) < 0) {
 		dprintf(N_WARNING,
 			"process_hosts: can't bind to reserved port\n");
 	}

Re: Random UDP port assignment for rpc.statd

[Trond Myklebust]

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

su den 20.02.2005 Klokka 10:30 (-0500) skreiv Trond Myklebust:

> See if the attached patch doesn't fix things so that your 3rd rpc.statd
> port stays on the port specified by "-o"...

Here is the same patch in a slightly cleaner version (it gets rid of the
redundant comparison)...

Neil, could you please apply to the main nfs-utils tree?

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>

[-- Attachment #2: nfs-utils-1.0.7-fix_outgoing_port.dif --]
[-- Type: text/plain, Size: 1298 bytes --]

 Ehem...
  1) sin.sin_port is supposed to be in network order.
  2) bindresvport() is used to automatically choose the port for you.
     if you want to set the port yourself, use bind()
---
 rmtcall.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

Index: nfs-utils/utils/statd/rmtcall.c
===================================================================
--- nfs-utils.orig/utils/statd/rmtcall.c
+++ nfs-utils/utils/statd/rmtcall.c
@@ -65,7 +65,7 @@ statd_get_socket(int port)
 
 	memset(&sin, 0, sizeof(sin));
 	sin.sin_family = AF_INET;
-	sin.sin_port = port;
+	sin.sin_addr.s_addr = INADDR_ANY;
 	/*
 	 * If a local hostname is given (-n option to statd), bind to the address
 	 * specified. This is required to support clients that ignore the mon_name in
@@ -76,11 +76,18 @@ statd_get_socket(int port)
 		if (hp)
 			sin.sin_addr = *(struct in_addr *) hp->h_addr;
 	}
+	if (port != 0) {
+		sin.sin_port = htons(port);
+		if (bind(sockfd, &sin, sizeof(sin)) == 0)
+			goto out_success;
+		note(N_CRIT, "statd: failed to bind to outgoing port, %d\n"
+				"       falling back on randomly chosen port\n", port);
+	}
 	if (bindresvport(sockfd, &sin) < 0) {
 		dprintf(N_WARNING,
 			"process_hosts: can't bind to reserved port\n");
 	}
-
+out_success:
 	return sockfd;
 }
 

Re: Random UDP port assignment for rpc.statd

[Haakon Riiser]

[Trond Myklebust]

> su den 20.02.2005 Klokka 10:30 (-0500) skreiv Trond Myklebust:

>> See if the attached patch doesn't fix things so that your 3rd
>> rpc.statd port stays on the port specified by "-o"...

> Here is the same patch in a slightly cleaner version (it gets
> rid of the redundant comparison)...

Works great -- thanks for fixing this so quickly!

-- 
 Haakon


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Haakon Riiser]

> Btw, there's also a similar problem with nfsd:  In addition to
> the standard listening port at 2049, it always opens a random
> port in the high port range (32000-32768 or something like that).

I almost forgot this one.  Does nfsd's mystery UDP port have the
same purpose as the one from statd, i.e. communication with the
portmapper?

-- 
 Haakon


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Trond Myklebust]

su den 20.02.2005 Klokka 18:21 (+0100) skreiv Haakon Riiser:
> > Btw, there's also a similar problem with nfsd:  In addition to
> > the standard listening port at 2049, it always opens a random
> > port in the high port range (32000-32768 or something like that).
> 
> I almost forgot this one.  Does nfsd's mystery UDP port have the
> same purpose as the one from statd, i.e. communication with the
> portmapper?

Which nfsd? knfsd or the userland server?

The nfsd also needs to register with the portmapper, but again, that
should close immediately after use. There should be no UDP ports kept
open other than 2049.

The lockd daemon needs an extra port, but you can control that (and this
control mechanism _should_ work) using the pseudofiles
in /proc/sys/fs/nfs, or the kernel parameters lockd.udpport and
lockd.tcpport.

Cheers,
 Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Haakon Riiser]

[Trond Myklebust]

> su den 20.02.2005 Klokka 18:21 (+0100) skreiv Haakon Riiser:

>> I almost forgot this one.  Does nfsd's mystery UDP port have
>> the same purpose as the one from statd, i.e. communication
>> with the portmapper?

> [...]
> The lockd daemon needs an extra port, but you can control that
> (and this control mechanism _should_ work) using the pseudofiles
> in /proc/sys/fs/nfs, or the kernel parameters lockd.udpport
> and lockd.tcpport.

Thanks, this works when I prefix udpport and tcpport with "nlm_".
But I see you already know that: :-)
http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1915.html

-- 
 Haakon


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Neil Brown]

On Sunday February 20, trond.myklebust@fys.uio.no wrote:
> su den 20.02.2005 Klokka 10:30 (-0500) skreiv Trond Myklebust:
> 
> > See if the attached patch doesn't fix things so that your 3rd rpc.statd
> > port stays on the port specified by "-o"...
> 
> Here is the same patch in a slightly cleaner version (it gets rid of the
> redundant comparison)...
> 
> Neil, could you please apply to the main nfs-utils tree?

Done.  Thanks.

NeilBrown


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Random UDP port assignment for rpc.statd

[Sven Köhler]

> Why isn't it possible to specify all of statd's listening ports
> using the -p flag?  It works for the TCP port and one of the
> UDP ports, but there is always one more listening UDP port that
> is randomly assigned.  I googled around for information on this
> problem, and came up with this Debian bug report:
> 
>   http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg11985.html
> 
> The thread ends with "I think we may have a real bug", but this
> was reported in 1.0.6, and the problem still persists in 1.0.7,
> so I was wondering if this isn't a bug after all.
> 
> Btw, there's also a similar problem with nfsd:  In addition to
> the standard listening port at 2049, it always opens a random
> port in the high port range (32000-32768 or something like that).
> 
> In case it matters:  I'm using Linux 2.6.10 and Slackware 10.1.

All that matters is "rpcinfo -p". As you can see, i managed to get 
everything on a specifig port:

# rpcinfo -p
    Program Vers Proto   Port
     100000    2   tcp    111  portmapper
     100000    2   udp    111  portmapper
     100024    1   udp  30002  status
     100024    1   tcp  30002  status
     100003    2   udp   2049  nfs
     100003    3   udp   2049  nfs
     100021    1   udp  30004  nlockmgr
     100021    3   udp  30004  nlockmgr
     100021    4   udp  30004  nlockmgr
     100005    1   udp  30001  mountd
     100005    1   tcp  30001  mountd
     100005    2   udp  30001  mountd
     100005    2   tcp  30001  mountd
     100005    3   udp  30001  mountd
     100005    3   tcp  30001  mountd

You can ok any other port in your firewall.

You may want to have those two lines in your /etc/sysctl.conf:
   fs.nfs.nlm_udpport=30004
   fs.nfs.nlm_tcpport=30004

I still have problems with rquotad though. It doesn't to be possible to 
set that on a static port.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: Random UDP port assignment for rpc.statd

[Dan Stromberg]

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


Do linux' NFS daemons use a dynamically linked (libc?) library function
or functions to get their port numbers mapped to something more or less
random?

If so, it might be possible (and interesting) to create an
LD_PRELOAD'able teensy .so that would replace this/these function(s)
with something that knows how to hardcode a port from a table under /etc
or something, and falls back on the traditional method of port
allocation otherwise.

On Mon, 2005-02-28 at 04:32 +0100, Sven Köhler wrote:
> > Why isn't it possible to specify all of statd's listening ports
> > using the -p flag?  It works for the TCP port and one of the
> > UDP ports, but there is always one more listening UDP port that
> > is randomly assigned.  I googled around for information on this
> > problem, and came up with this Debian bug report:
> > 
> >   http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg11985.html
> > 
> > The thread ends with "I think we may have a real bug", but this
> > was reported in 1.0.6, and the problem still persists in 1.0.7,
> > so I was wondering if this isn't a bug after all.
> > 
> > Btw, there's also a similar problem with nfsd:  In addition to
> > the standard listening port at 2049, it always opens a random
> > port in the high port range (32000-32768 or something like that).
> > 
> > In case it matters:  I'm using Linux 2.6.10 and Slackware 10.1.
> 
> All that matters is "rpcinfo -p". As you can see, i managed to get 
> everything on a specifig port:
> 
> # rpcinfo -p
>     Program Vers Proto   Port
>      100000    2   tcp    111  portmapper
>      100000    2   udp    111  portmapper
>      100024    1   udp  30002  status
>      100024    1   tcp  30002  status
>      100003    2   udp   2049  nfs
>      100003    3   udp   2049  nfs
>      100021    1   udp  30004  nlockmgr
>      100021    3   udp  30004  nlockmgr
>      100021    4   udp  30004  nlockmgr
>      100005    1   udp  30001  mountd
>      100005    1   tcp  30001  mountd
>      100005    2   udp  30001  mountd
>      100005    2   tcp  30001  mountd
>      100005    3   udp  30001  mountd
>      100005    3   tcp  30001  mountd
> 
> You can ok any other port in your firewall.
> 
> You may want to have those two lines in your /etc/sysctl.conf:
>    fs.nfs.nlm_udpport=30004
>    fs.nfs.nlm_tcpport=30004
> 
> I still have problems with rquotad though. It doesn't to be possible to 
> set that on a static port.
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]