I've found what looks to me like a bug in our TCP's handlign of
FIN_WAIT_2 sockets.  Before "fixing" it, I thought I'd ask to see if it
really is deliberate.

As I read it, FIN_WAIT_2 is the state for a socket whose send side has
been shut down but whose receive side is still up.  (Well, one of the
states; FIN_WAIT_1 is similar, but before our FIN has been ACKed.)

As such, FIN_WAIT_2 is a legitimate long-term state; a client that
connects to a server, sends a request, and then shuts down its send
side should still be able to receive data from the server.

The problem is, that's not the way we work.  If the peer is slow about
sending data, we will unilaterally terminate the connection without
making any attempt to find out whether the peer TCP thinks the
connection is still alive: tcp_usrclosed() [tcp_usrreq.c] sets the 2MSL
timer going, and if it expires before the peer decides to send us
something (or if, after it expires, the peer lets the connection idle
for more than tcp_keepintvl), we will tcp_close() the connection (see
tcp_timers() [tcp_timer.c], case TCPT_2MSL).

It seems to me that tcp_usrclosed should use the keepalive timer, not
the 2MSL timer, in this case, since a keepalive probe seems to me to be
the correct thing to send in this case.

Comments?  Have I gotten confused, or is this really a problem?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B