Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!forys
From: forys@sigi.Colorado.EDU (Jeff Forys)
Newsgroups: comp.unix.wizards
Subject: Re: netstat tables
Summary: Buggy TCP implementation
Keywords: netstat, nfs, ftp
Message-ID: <3536@sigi.Colorado.EDU>
Date: 17 Dec 87 23:02:35 GMT
References: <829@gargoyle.UChicago.EDU>
Reply-To: forys@boulder.Colorado.EDU (Jeff Forys)
Distribution: na
Organization: University of Colorado, Boulder
Lines: 58

In article <829@gargoyle.UChicago.EDU> (Ronald A. Thisted) writes:
> When I ftp to a particular computer (chip) on our local net, and if I
> send a file to that machine from my local machine, on exit from ftp I
> find that I have added a permanent entry into the active connections
> table produced by netstat [...]

> 1) what is going on

The problem is not with `ftp'.  Rather, your side of the TCP session
is getting stuck in FIN-WAIT-2 (awaiting a FIN from the other side).
This particular FIN will never arrive; if it happens often with the
same target, it's due to a bug in your targets' TCP implementation.

What normally happens is the session in FIN-WAIT-2 should receive
a FIN, send an ACK, and then move into the TIME-WAIT state.  Where,
after an implementation dependent (albeit brief) period of time,
the timer (termed "2MSL") expires, the TCP Protocol Control Block
is deleted, and the session terminated.

> 2) whether I can manually remove (kill, close?) the offenders (short of
>    reboot)

You can tweak the state of the connection from FIN-WAIT-2 to CLOSED.
You may also be able to put the session into TIME-WAIT by setting the
2MSL timer to be greater than 0.  There are assorted adb scripts and
C programs around, that let you do this wonderful thing.  If you cant
find one, drop me a note.

> 3) whether there is risk of filling up a table of some sort (if I just
>    ignore the problem)

About the only thing you will waste by `ignoring the problem' is a
couple mbuf's.  It should not be harmful, unless you are low on them.

> 4) whether the apparent degradation in load could be due to this phenomenon

Doubt it.  The PCB is just a linked list of active connections.  A few
FIN-WAIT-2 entries may waste a *little* time when searching, but should
not be the cause of noticeable degradation.

> 5) whether the fault is likely to be local or remote

That depends on who initiated the close sequence (by issuing the
FIN-WAIT-1).  Whoever sends the FIN-WAIT-1 first is most likely *not*
the guilty party (they did not close at the same time, otherwise you
wouldnt be in FIN-WAIT-2).  Seeing as you were using FTP, the other side
probably closed first and you are at fault.  You mention you are running
4.2BSD, and there was just such a bug with that TCP implementation.

> 6) what I might do to remedy the situation.

Permanently?  You can run a 4.3BSD variant TCP implementation, or better
still, get hold of Van Jacobson's TCP (which, BTW, will be used in 4.4BSD).
You can also clear FIN-WAIT-2 automatically after a certain period of time,
but that can cause other undesirable side effects (i.e. dont do it :-).
---
Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991)
forys@boulder.Colorado.EDU  -or-  ..!{hao|nbires}!boulder!forys