Subject: HP-UX -11.0 (FIN_WAIT_2)

From: vijay singh <[email-masked]>
Date: Thu, 29 Jun 2000 14:08:16 -0700 (PDT)

Hello,

is anyone on the list aware of problems on the HP UX
TCP stack implementation, wherein a connection in the
FIN_WAIT_2 state remains so indefinitely. This may
have happened as the application (client) exited
without closing the socket. Specifically I have the
following questions:

1. Is there a known problem like this?
2. Is there a way to drop a connection (with the tuple
obtained from netstat) without recycling the kernel?
3. What are the consequences of issuing a *shutdown*
and immediately following it with a *close*?

Any help is appreciated.
Vijay

=====
VIJAY SINGH
41 W Brown Street,
Apt# 7,
Somerville - NJ 08876.
Ph (H) - (908)575-3255
   (O) - (973)360-3148.
E-MAIL: [email-masked]

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

---

From: Rick Jones <[email-masked]>
Date: Thu, 29 Jun 2000 15:37:47 -0700

> 1. Is there a known problem like this?

Not that I happen to be aware of, but you can search the databases in
the HP "IT RC" (support web site) which you can find via links from
http://www.hp.com/ . Just how "indefinite" has your indefinite been
shown to be at this point?

> obtained from netstat) without recycling the kernel?

It shouldn't be necessary to do either - upon entering a "detached"
state the stack will automagically start a timer based on the setting of
tcp_keepalive_detached_interval (see ndd -h
tcp_keepalive_detached_interval for more info). If the remote is not
responding to the keepalive probes, the endpoint should go away within
tcp_ip_abort_interval milliseconds. 

If the remote is still responding to the probes, the endpoint will
remain.

How many of these endpoints are there on your system, and what do you
want to accomplish that their presence is precluding?

> and immediately following it with a *close*?

Nothing untoward - the netperf benchmark does something akin to that all
the time.

rick jones
-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

---

From: Scott Millward <[email-masked]>
Date: Thu, 29 Jun 2000 16:35:20 -0700

Hello,

On 11.0 there is an algorithm that extends the keepalive probes during
the FIN_WAIT_2 state.  This was to prevent an time-based drop of the
connection half without really knowing if the other half was really
gone, or just delaying their close.  The BSD Stack has a timer that
silently drops the connections in FIN_WAIT_2 after a specified interval.

Due to popular demand ;-) .. The old BSD style FIN_WAIT_2 timer can be
enabled in the HPUX 11.0 stack if you have a recent Transport Patch
level. (The latest patch ID for Transport as of today is PHNE_21767)

Following is a write up on how you would enable this:

--------------------------------------------------------------------

There is an ndd parameter, post-patch PHNE_19375/11.0, that is called

  tcp_fin_wait_2_timeout

This parameter sets the fin_wait_2 timer on 11.X to stop idle fin_wait_2
connections. It will not survive a reboot, so modification of the
/etc/rc.config.d/nddconf is a necessary.

It specifies an interval, in milliseconds, after which the TCP will be
unconditionally killed.  An appropriate reset segment will be sent when
the connection is killed.

The default for tcp_fin_wait_2_timeout is 0, which allows the connection
to live forever, as long as the far side continues to answer keepalives.

To enable the tcp_fin_wait_2 timer to timeout do the following:

1. To get the current value (0 is turned off):
   # ndd -get /dev/tcp tcp_fin_wait_2_timeout 0

2. To set the value to 20 min's:
   # ndd -set /dev/tcp tcp_fin_wait_2_timeout 1200000

3. Check the setting:
   # ndd -get /dev/tcp tcp_fin_wait_2_timeout 1200000

Note: (1000 ms in 1 second) * (60 seconds) * (20 minutes)= 1200000 ms.
20 minutes is just an example but probably a good selection.

This will not survive a reboot, so you need to update

  /etc/rc.config.d/nddconf

with the parameter so that it will be set at boot time.

  TRANSPORT_NAME[0]=tcp
  NDD_NAME[0]=tcp_fin_wait_2_timeout
  NDD_VALUE[0]=1200000

NOTE: patches may be superceded, verify your patch levels via the patch
database on the IT resource Center.

For more information regarding Transmission Control Protocols See RFC
793

---

From: Ramesh Shankar <[email-masked]>
Date: Thu, 29 Jun 2000 17:43:02 -0600

Did you check up RFC 2525, known TCP implementation problems? I thought
this one was mentioned in there.

Thanks,

S.R.