It is still in Established state after 13 hours .
2010-5-31 1:40:29 state information
tcp4 0 0 10.7.127.104.6553 10.7.184.23.61537 ESTABLISHED
tcp4 0 0 10.7.127.104.6553 10.7.184.23.65274 ESTABLISHED
2010-5-31 14:43:30 state information
tcp4 0 0 10.7.127.104.6553 10.7.184.23.61537 ESTABLISHED
tcp4 0 0 10.7.127.104.6553 10.7.184.23.65274 ESTABLISHED
Now I am doing the tcpdump in my AIX server , the file size is still 0 after about 10 minutes .
According to MR.Andrew point , if the SO_KEEPALIVE option is 0 which is set by application , so these 2 connection will be in Established state for ever ?
On Mon, May 31, 2010 at 6:16 AM, Andrew Hood
<ajhood@xxxxxxxxx> wrote:
Bo Xu wrote:
> Hello Guys ,
>
> Today I have found 2 TCP connection is in ESTABLISH state while the
> peer side said they have already disconnected the connection ,
>
> but even they stopped the application , the 2 TCP connection is till there
> :( .
>
> Now I am wondering when the OS will release these 2 fake ESTABLISH
> connection . I digged this issue by google , and I have found
>
> these parameter in my OS which is AIX 5.8 . So AIX will release these 2
> connection according the tcp_keepidle (2 hours ) , Am I right ?
>
> And what tcp_keepintvl stands for ?
>
> tcp_keepidle = 14400
> tcp_keepinit = 150
> tcp_keepintvl = 150
Let me guess. The AIX and peer are separated by a firewall.
There was an APAR applied to AIX 4.3.3 and built in to all later
versions to force AIX to behave according to RFC 1122. This requires
that tcp keepalives only be sent if the application explicitly requests
them. This is done by calling setsockopt() with the SO_KEEPALIVE option
value set to 1.
I have never been able to find an option to restore the non-RFC
compliant behaviour, and this cause us lots of grief.
The only way to get those connections to close is to create a new
connection from the peer with that same port numbers, or fake an RST
packet, or stop/start the process owning them.
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
