tcp socket to mountd port in time_wait state in linux-- how to recover??

[smileso...@gmail.com]

Hi all,
I am using Linux 6.4. When I am trying to mount from the client from a program via the tcp socket the server closes the tcp socket after reaching the state TIME_WAIT.
I have disabled the iptables rules. But still it doesnot help.

I think I am having similar problem as mentioned in below thread.

http://www.spinics.net/lists/linux-nfs/msg13036.html

I have a couple of questions:

1. How can i recover from this state?

[root@hostarena~]# netstat -tp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 hostarena.yyy.org:49423 hostblob.yyy.org:33973 TIME_WAIT -
[root@hostarena ~]

the /var/log/messages after enabling the rpc_debug didnot show anything meaningful.

NFS Server is listening for mount requests at port 49423. I am suspecting time_wait state is due to the fact that source-port is > 1024(i.e 33973) for root.

2. Is there a way i can configure the linux nfs server to accept from non- reserved port > 1024?

3. Is there a way i can tell the client socket to choose the source ports < 1024 for mount without changing the /proc/sys/net/ipv4/ip_local_port_range at the client?

I appreciate somebody can throw some light to fix the issue?

Note: All the RPC services are running at the NFS server(confirmed by rpcinfo -p)

Regards
Pradeep

[J.O. Aho]

On 27/12/13 16:12, smileso...@gmail.com wrote:
> Hi all,
> I am using Linux 6.4.

Latest version of Linux is just 3.12.6 and 3.13.0 soon to be releasedl.
If the version number is for your distribution, then you should state
the distribution name instead, say CentOS 6.4.

> When I am trying to mount from the client from a program via the tcp socket the server closes the tcp socket after reaching the state TIME_WAIT.
> I have disabled the iptables rules. But still it doesnot help.

Are the rpc services up and running on the client (and on the server)
liek rpcbind, rpc.statd and rpc.idmapd (this used to be handled by the
portmap service).

> I think I am having similar problem as mentioned in below thread.
>
> http://www.spinics.net/lists/linux-nfs/msg13036.html
>
> I have a couple of questions:
>
> 1. How can i recover from this state?
>
> [root@hostarena~]# netstat -tp
> Active Internet connections (w/o servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
> tcp 0 0 hostarena.yyy.org:49423 hostblob.yyy.org:33973 TIME_WAIT -
> [root@hostarena ~]
>
> the /var/log/messages after enabling the rpc_debug didnot show anything meaningful.
>
> NFS Server is listening for mount requests at port 49423. I am suspecting time_wait state is due to the fact that source-port is > 1024(i.e 33973) for root.
>
> 2. Is there a way i can configure the linux nfs server to accept from non- reserved port > 1024?

Thats the default.

> 3. Is there a way i can tell the client socket to choose the source ports < 1024 for mount without changing the /proc/sys/net/ipv4/ip_local_port_range at the client?

No.

> I appreciate somebody can throw some light to fix the issue?
> Note: All the RPC services are running at the NFS server(confirmed by rpcinfo -p)

What about the client side?
Checked that route is okey on the server, so packages is routed back the
same way?

--

//Aho

[smileso...@gmail.com]

On Saturday, December 28, 2013 2:36:07 AM UTC+5:30, J.O. Aho wrote:
> On 27/12/13 16:12, smileso...@gmail.com wrote:
>
> > Hi all,
>
> > I am using Linux 6.4.
>
>
>
> Latest version of Linux is just 3.12.6 and 3.13.0 soon to be releasedl.
>
> If the version number is for your distribution, then you should state
>
> the distribution name instead, say CentOS 6.4.
>
>
>
>
>
> > When I am trying to mount from the client from a program via the tcp socket the server closes the tcp socket after reaching the state TIME_WAIT.
>
> > I have disabled the iptables rules. But still it doesnot help.
>
>
>
> Are the rpc services up and running on the client (and on the server)
>
> liek rpcbind, rpc.statd and rpc.idmapd (this used to be handled by the
>
> portmap service).
>

> All the services is running in client and server because manually mount succeeded. Only through testprogram it is not working.

>
> > I think I am having similar problem as mentioned in below thread.
>
> >
>
> > http://www.spinics.net/lists/linux-nfs/msg13036.html
>
> >
>
> > I have a couple of questions:
>
> >
>
> > 1. How can i recover from this state?
>
> >
>
> > [root@hostarena~]# netstat -tp
>
> > Active Internet connections (w/o servers)
>
> > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
>
> > tcp 0 0 hostarena.yyy.org:49423 hostblob.yyy.org:33973 TIME_WAIT -
>
> > [root@hostarena ~]
>
> >
>
> > the /var/log/messages after enabling the rpc_debug didnot show anything meaningful.
>
> >
>
> > NFS Server is listening for mount requests at port 49423. I am suspecting time_wait state is due to the fact that source-port is > 1024(i.e 33973) for root.
>
> >
>
> > 2. Is there a way i can configure the linux nfs server to accept from non- reserved port > 1024?
>
>
>
> Thats the default.
>
>
>
> > 3. Is there a way i can tell the client socket to choose the source ports < 1024 for mount without changing the /proc/sys/net/ipv4/ip_local_port_range at the client?
>
>
>
> No.
>
>
>
>
>
> > I appreciate somebody can throw some light to fix the issue?
>
> > Note: All the RPC services are running at the NFS server(confirmed by rpcinfo -p)
>
>
>
> What about the client side?
>
> Checked that route is okey on the server, so packages is routed back the
>
> same way?
>
>

> telnet succeded to the connect to server. So I guess routing is ok.
> --
>
>
>
> //Aho