TCPIP connection Query

[Charles Harris]

Dear all,

I'm currently trying to figure out a way of removing stale port connections on one of our servers, with out rebooting. Does anyone know of a way to remove FIN_WAIT connections by force? - I know these are supposed to time out, but I'd like to get rid of them asap. I can't locate the daemon running that services the port in question (it crashed, but left a user connected) and I can't now restart it because the port is in use.

Any tips, pointers, explanation warmly received!!!

Thanks!

-ChaZ-

[Sanjay_6 · Accepted solution]

Hi Charles,

Take a look at the thread below for more info.

http://us-support.external.hp.com/cki/bin/doc.pl/sid=c68afaf2035134a852/screen=ckiDisplayDocument?docId=200000050068096

hope this helps.

Regds

[harry d brown jr]

Please read this thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xa7d9a1abbac8d5118ff10090279cd0f9,00.html

live free or die
harry

[Roger Baptiste]

Hi,

In addition to the info
given in the thread, this
should be of some help:

this applies if you are using
11.00 :
**
# ndd -get /dev/tcp tcp_fin_wait_2_timeout

Note: The default is zero (0), which indicates an infinite wait for the
connection to be dropped. You can interpret any value other than zero as
a millisecond value.

You can execute this command to change the value to 1 minute:

# ndd -set /dev/tcp tcp_fin_wait_2_timeout 60000
***

-raj

[Charles Harris]

Great, thanks for the support, I knew I'd come across this before, but I couldn't remember the best way of doing it! - Thanks for the cut-down version Raj, it did the trick!

Thanks again!

-ChaZ-

[rick jones]

quite frankly, I can not think of a situation where FIN_WAIT_* connections need to be culled by force except for an application bug when the app will not restart because it does not set SO_REUSEADDR.

one really should get such apps fixed.

indeed FIN_WAIT_1 is an active retransmission state and will terminate in no more than tcp_ip_abort_interval

when an application calls close() and thus "detaches" from the TCP endpoint, that endpoint, when in FIN_WAIT_2 state start sending TCP keepalives after tcp_deepalive_detached_interval, and will keep sending them for no more than tcp_ip_abort_interval before toasting the endpoint.

FIN_WAIT_2 can also be entered by apps which call shutdown(SHUT_WR) to put the TCP connection in a perfectly valid, receive-only state. if one sets that tcp_fin_wait_timer, it may arbitrarily nuke such connectoins, much to their chagrin.

the only time the FIN_WAIT_2 TCP keepalives (tcp_keepalive_detached_interval) do not kill a connection is when the remote endpoint is still there - such as that receive-only situation, or broken firewalls that haven't maintained connection state properly