Netstat problem

[Patrick Chim]

Hi,

My HP-UX running 11.0 has found many tcp connections established. They seem not to go away even though the connection of the client is closed. Is there any command to terminate the connection if I know the connecting IP ? If it does, will it have any problem ?

Regards,
Patrick

[Vincenzo Restuccia]

Try with lsof,get http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.55/

[Bill McNAMARA_1]

connecting IP try
who -R

Later,
Bill

[Abel Berger]

Hi Patrick,

In this box, you run many applications or databases ?? What applications it run ?

Regards,

Abel Berger

[rick jones]

what is your definition of "many" in this sutiation? also, in what state or states do you find the connections? depending on the states they will go away on their own after some period of time.

[Brian Hackley · Accepted solution]

Patrick,

What state are the connections in as viewed in netstat -a / netstat -an ?
If they are FIN_WAIT_2 and ARPA transport PHNE_19375 or later use following hidden and unsupported ndd:
Check the current value:

ndd -get /dev/tcp tcp_fin_wait_2_timeout

EXAMPLE: Set the FIN_WAIT2 timeout to 11 minutes:
ndd -set /dev/tcp tcp_fin_wait_2_timeout 660000

nddconf entry example:
TRANSPORT_NAME[0]=tcp
NDD_NAME[0]=tcp_fin_wait_2_timeout
NDD_VALUE[0]=660000

If connection in some other state there are more drastic measures but don't suggest them for production systems.

hope this helps,

-> Brian Hackley

[MANOJ SRIVASTAVA]

Hi Patrick

It looks like this

1. A Port gets opened as a thread of the process , so to know which one is hanging you need to find out which port is opened , which porcess it is attached to .Download lsof and install it form :
http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof

and then run lsof , grep for the port no. it will show you where it is attached to . : netstat -an will give you the exact process for that port , and then you can go ahead and kill the process to stop that port which has hung.

Manoj Srivastava

[rick jones]

i thought that fin_wiat_2_timeout kludge was only required if apps did the shutdown()read()close() sort of exchange for connection teardown. otherwise, if they just call close, tcp_keepalive_detached_interval will kick-in automagically for FIN_WAIT_2 connections since they will be "detached" from the socket (thanks to the close() call)

the "danger" with the arbitrary tcp_fin_wait_2_timeout kludge is that FIN_WAIT_2 in a non-detached state can be a perfectly valid "recieve-only" state and so the timeout could nuke what was an otherwise good connection.