Port Hang

[Smirjit Singh]

Dear All,

I don't have very good knowledge in HP Networking. I am facing a problem. My system (10.20) is being unable to initialize any port. When I am giving netstat -an then it is showing lot of port is showing FIN_WAIT_2 and TIME_WAIT & CLOSED. I think only for this reason it is not being able to initialize new port. Can anybody explain whats are the meanning of above value. I had to reboot. Actually I am running Apache & Apache J Server. From Apache it is calling Apache Jserver. Apache is running in 8006 port & Jserver is running in 8007 port. But when I stop & restart Apache it is being able to initialize 8006 no port but not 8007 port. So Jserver is not running. I tried to check it by lsof -p command .. It does not show anything.
Would u pls help me on it ?

Can you give some good URL where I can clear my idea on it.

Thanks in advance

[Berlene Herren · Accepted solution]

To affect the FIN_WAIT_2 states, you can issue
(need recent ARPA transport patch)
#nettune -s tcp_fin_wait_timer 600
(Units in seconds)

Remember nettune changes do not do not survive reboots! Create a startup file in /sbin/rc2.d typically /sbin/rc2.d/S341nettune that runs the nettune(s) that you need.

As to the other states, these are normal TCP states. ITRC has a great document that explains them, NSCP980710-11.

Another excellent source is TCP/IP Illustrated, Vol 1, but Wright Stevens.

Regards,
Berlene

[Smirjit Singh]

Hi Berlene,

Thanks for your answer.. I did not get that document which ID you have given. I think to get these document I need some special access code.

Ok can you tell me how I can configure maximum open port. Means how much port would be open simultenaously.

Thanks in advance.

Your point will be rewarded

[Smirjit Singh]

Hi Berlene,

This problem has occured after installing patch PHNE_22507. I am giving output in below.tcp 0 0 208.221.13.101.2552 208.221.13.101.1041 FIN_WAIT_2
tcp 72 0 172.20.1.22.1041 172.20.1.22.2542 CLOSE_WAIT
tcp 0 0 172.20.1.22.2542 172.20.1.22.1041 FIN_WAIT_2
tcp 72 0 208.221.13.101.1041 208.221.13.101.2500 CLOSE_WAIT
tcp 0 0 208.221.13.101.2500 208.221.13.101.1041 FIN_WAIT_2
tcp 72 0 172.20.1.22.1041 172.20.1.22.2491 CLOSE_WAIT
tcp 0 0 172.20.1.22.2491 172.20.1.22.1041 FIN_WAIT_2
tcp 72 0 208.221.13.101.1041 208.221.13.101.2464 CLOSE_WAIT
tcp 0 0 208.221.13.101.2464 208.221.13.101.1041 FIN_WAIT_2
tcp 72 0 172.20.1.22.1041 172.20.1.22.2456 CLOSE_WAIT
tcp 0 0 172.20.1.22.2456 172.20.1.22.1041 FIN_WAIT_2
tcp 72 0 208.221.13.101.1041 208.221.13.101.2428 CLOSE_WAIT
tcp 0 0 208.221.13.101.2428 208.221.13.101.1041 FIN_WAIT_2
tcp 72 0 172.20.1.22.1041 172.20.1.22.2419 CLOSE_WAIT
tcp 0 0 172.20.1.22.2419 172.20.1.22.1041 FIN_WAIT_2
tcp 0 0 172.20.1.22.2413 172.20.5.120.6000 ESTABLISHED

When I giving lsof -p then it did not show anything. That means it is not running any process. But it is holding resource. Is their any procedure to get rid of this problem.

[rick jones]

do be careful with that arbitrary fin_wait_timer - FIN_WAIT_2 in some cases is a perfectly reasonable receive-only state for a TCP connection.

a server that is unable to restart with connections in any state other than LISTEN is likely broken. the likely bug is that the server is failing to set SO_REUSEADDR before trying to bind() to its well-known port number.

without that bug fixed, you have to wait for all the FIN_WAIT_*, TIME_WAIT, and CLOSE_WAIT connections to go away. FIN_WAIT_1 will go away after retransmit timeout, or will transition to FIN_WAIT_2. FIN_WAIT_2 will go away once the remote sends us a FIN, or if the app set SO_KEEPALIVE after the TCP keepalive settings (or if you use the fin_wait_timer kludge), CLOSE_WAIT will not go away until the application with the socket calls close().

so, you really really want server apps to be setting SO_REUSEADDR.

the cleanup of FIN_WAIT_2's is nicer on 11 with its tcp_keepalive_detached_interval that basically does keepalives after close() whether the app set SO_KEEPALIVE or not.

[Berlene Herren]

You can reboot to clear all the connections.
Sockets in FIN_WAIT_2 are common on web servers.

TIME_WAIT is caused when the server closes the connection with the client. The server keeps the socket open for at least 120 seconds. More information is included in the attached file.

Berlene

[Berlene Herren]

Thanks Rick! HP's TIME_WAIT is 60 seconds, not 120.

Berlene