Subject: Re: LOTS of TIME_WAIT

From: Aris Yannopoulos <[email-masked]>
Date: Tue, 2 Feb 1999 12:52:15 -0500 (EST)

> 
> > When running netstat on the server it shows huge amounts of data port
> > stuff in the state "TIME_WAIT"
> > 
> > Any thoughts? DoS attempt? Stateless requests?

> Old version?  Probably.

If VR12 is an old version already, we're in trouble :)

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 2 Feb 1999 13:37:24 -0500 (EST)

> If VR12 is an old version already, we're in trouble :)

you didn't say what version you were running before.  older versions of
the daemon (circa beta-12) had a lot of problems with hangers-on.

time wait is the tcp state after a connection has closed that the
socketpair is kept arround so the kernel can cleanly dispose of any stray
packets.

many tcp stacks have an option either in the kernel or available to
applications which controls how long timewait lasts or if it even occurs.
the daemon uses the local default for this.

what I've noticed is a number of web clients open and close a large number
of connections to the ftp server rather than holding a single control
connection throughout the session.  each of those connections will have a
timewat socket hanging about for a few seconds afterwards (on my systems,
about 60 seconds).

if you're seeing a very large number, and traffic at your site is not high
enough to justify them, then I'd look for other causes.  for instance, is
it possible there's a communications error causing the connections to
report errors and be closed?

while it's possible to construct a DoS using timewait (ISTR there have
been such in the past), only older kernels (2+years) should be
susceptible.

I'd suggest making sure you're using the latest patches from your vendor
(or, for Linux and such, the latest stable kernel) and observing your
system for a while with that.

closing question: do you have a specific test you run locally which causes
the problem or is it only observed in the wild?

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Thomas Neshite <[email-masked]>
Date: Tue, 2 Feb 1999 14:55:25 -0500 (EST)

I had a problem for quite a while regarding TCP connections not
 closing properly. Mine was hanging in FIN_WAIT_2 state. Running
 HPUX, finally tracked down a patch released by HP that allowed you to 
 configure a  kernel memory value (the "FIN_WAIT timer"). If a
 connection was stuck in FIN_WAIT_2 for more than the timeout value
 the connection was automatically terminated. There were times when
 I had hundreds of finwaits, they finally ate up all the network
 sockets and no one else could connect. Once I installed the vendor
 os patch everything worked great.

 tjn