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/[email protected]/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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/[email protected]/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 <[email protected]>
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
[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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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");
}
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;
}
[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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> 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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 <[email protected]>
-------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
[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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sunday February 20, [email protected] 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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> 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/[email protected]/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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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/[email protected]/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 - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
>