Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!mike@brl-tgr
From: mike@brl-tgr (Mike Muuss)
Newsgroups: net.unix-wizards
Subject: FIN_WAIT_2 Warning:  JSQ \"fix\" bad!
Message-ID: <10173@brl-tgr.ARPA>
Date: Tue, 23-Apr-85 23:15:26 EST
Article-I.D.: brl-tgr.10173
Posted: Tue Apr 23 23:15:26 1985
Date-Received: Fri, 26-Apr-85 21:24:44 EST
Sender: news@brl-tgr.ARPA
Lines: 22

The recently re-posted John Quarterman "fix" for hanging FIN_WAIT_2
connections is *bad*, in a subtle and dangerous way.  We had it installed
for several weeks before we noticed why it was bad.  I have commented
on the list before about this, but it is worth repeating.

A connection may operate correctly in FIN_WAIT_2 state forever.
A good example of this is the following command line:

	rsh tgr batchnews < /dev/null | unbatchnews

The RSH will sense EOF on stdin immediately, and do an advisory
close on the TCP connection *TO* machine "tgr", yet data will continue
to flow *FROM* machine "tgr" for hours.  This connection operates
in FIN_WAIT_2 state the whole time -- THIS IS CORRECT FUNCTION.

If you choose to install JSQ's fix anyways, just remember that
any RSH that you run from a shell file had better run quickly
(ie, within the FIN_WAIT_2 timeout you pick), or the connection
will be broken for you.

Best,
 -Mike Muuss