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