TIME_WAIT problems - netstat -an

[sapi]

all,

I have a problem in my server application.
i used rp8400, hpux 11.11 and running cluster.
the problem is thera are many TIME_WAIT when i run netstat -an. I just tried to down the interface, after interface down, TIME_WAIT is gone but after interface up again, there are many of TIME_WAIT.

bash-2.04$ ndd -get /dev/tcp tcp_time_wait_interval
60000
bash-2.04# netstat -a | grep TIME
tcp 0 0 eaipapp1.60234 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60257 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60201 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60220 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60363 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60369 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60294 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60329 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60337 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60022 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60029 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59912 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59927 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59946 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60106 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60107 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60108 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60109 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60113 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60033 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60043 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60049 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60060 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60069 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60093 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60094 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59851 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59856 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59887 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59899 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59786 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59804 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59817 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59825 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59830 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59835 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59838 .5000 TIME_WAIT
tcp 0 0 eaipapp1.59839 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60674 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60675 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60680 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60685 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60687 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60688 .5000 TIME_WAIT
tcp 0 0 localhost.60119 localhost.hacl-local TIME_WAIT
tcp 0 0 localhost.60120 localhost.hacl-local TIME_WAIT
tcp 0 0 localhost.60121 localhost.hacl-local TIME_WAIT
tcp 0 0 eaipapp1.60495 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60421 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60432 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60433 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60467 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60610 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60629 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60639 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60644 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60650 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60652 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60656 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60660 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60663 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60665 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60668 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60670 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60671 .5000 TIME_WAIT
tcp 0 0 eaipapp1.60607 .5000 TIME_WAIT
bash-2.04#


help me, please !

[Arunvijai_4]

Hello,

Dont forget to check these thread

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=926850
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=120926

-Arun

[Muthukumar_5]

check the network tuning parameter,

# ndd -h tcp_time_wait_interval

tcp_time_wait_interval:

Amount of time TCP endpoints persist in TCPS_TIME_WAIT state.
[1000,600000] Default: 60000 (60 seconds)

Tune it to suit your requirement. Configure /etc/rc.config.d/nddconf file to get permanent effect.

--
Muthu

[Senthil Kumar .A_1 · Accepted solution]

Hi,

The value for tcp tcp_time_wait_interval as 60000 just indicates a wait time of 60000 Milliseconds, that is effectively 1 minute. This state is a part of TCP handshaking procedure and is normal. For complimenting your understanding, I have attached the TCP handshake diagram and also a link which could help in this respect...


http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html

regards,
Senthil Kumar .A

[sapi]

I have already set tcp_time_wait_interval to 30000 (0.5 minute), TIME_WAIT connection is reduce but still more TIME_WAIT conn.
bash-2.04# netstat -an | grep tcp | grep 5000 | awk '{print $6}'| sort | uniq -c
48 ESTABLISHED
1 LISTEN
968 TIME_WAIT

for grep above, port in socket use 5000. i checked in /etc/services, there is no port 5000 established in my system.

[Muthukumar_5]

Set tcp_time_wait_interval to 60000 and try to restart your application again.

--
Muthu

[Arunvijai_4]

Hello,

You may have some kind of attack in your network,

http://www.linklogger.com/TCP5000_Overflow.htm

-Arun

[sapi]

arun,

so, what can I do ?


-yut-

[Arunvijai_4]

Hello,

Shutdown the port, look for any patches available for all third party softwares installed on your system.

-Arun

[sapi]

how to shutdown ?

[Arunvijai_4]

Download lsof and install to findout which application is running or using port 5000.

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.76/

After installing, do # man lsof for more information.

-Arun

[rick jones]

Module the possiblity of lost of folks connecting to your service at port 5000 for nefarious porpoises, what makes you think that the very small (yes, that is actually small) number of TIME_WAIT connections shown in the initial posting is in any way a problem on your system?

The HP-UX networking stack can handle literally millions of connections in TIME_WAIT without undue stress. There should be no need to reduce tcp_time_wait_interval or otherwise try to circumvent what is an integral part of TCP's mechanisms to avoid silent data corruption.

[rick jones]

Module the possiblity of evil folks connecting to your service at port 5000 for nefarious porpoises, what makes you think that the very small (yes, that is actually small) number of TIME_WAIT connections shown in the initial posting is in any way a problem on your system?

The HP-UX networking stack can handle literally millions of connections in TIME_WAIT without undue stress. There should be no need to reduce tcp_time_wait_interval or otherwise try to circumvent what is an integral part of TCP's mechanisms to avoid silent data corruption.