Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Oct 2000 20:10:02 -0700 (PDT)
From:      Ryan Younce <ryan@manunkind.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/21791
Message-ID:  <200010170310.UAA68554@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/21791; it has been noted by GNATS.

From: Ryan Younce <ryan@manunkind.org>
To: freebsd-gnats-submit@FreeBSD.org,
	"jd @ dynw . com?subject=Re":%20kern/21791:%20Hang%20on%20FIN%5FWAIT%5F%32@cheshire.manunkind.org
Cc:  
Subject: Re: kern/21791
Date: Mon, 16 Oct 2000 23:08:54 -0400

 From what I can tell, this is not a fault with FreeBSD but a fault with the
 remote server.  The remote server fails to send a final FIN to the client,
 and the state of the connection remains in FIN_WAIT_2 indefinitely.  The
 same situation was reproduced with www.freebsd.org, and it succeeded in
 proceeding to the TIME_WAIT state.
 
 Thus, from what I can tell, faulty TCP implementations on remote machines
 will cause FreeBSD to hold connections in a FIN_WAIT_2 state for an indefinite
 period of time (I believe the OP said something on the order of several days).
 
 I have written a patch that pseudo-corrects this by not only testing whether
 or not the state is not TIME_WAIT (in sys/netinet/tcp_timer.c) but also if it
 is less than FIN_WAIT_2 (thus ruling out FIN_WAIT_2 or TIME_WAIT).  I tested
 this with FreeBSD 4.1.1-RELEASE and the FIN_WAIT_2's dropped out of netstat's
 output after 10 minutes (which the TCP code states it should do), even with
 the faulty remote server's implementation.
 
 Please review this code.  It has not been tested for current but it has been
 diffed with current sources.  The affected line has been tested with 4.1.1
 RELEASE and has at least indicated correct behavior.  If somebody out there
 with greater knowledge of TCP/IP networking sees a flaw, please bring this up.
 This marks my first attempt at debugging BSD networking kernel code so any
 suggestions would be appreciated.  Thank you.
 
 Ryan Younce
 
 --- tcp_timer.c.orig    Mon Oct  2 18:28:49 2000
 +++ tcp_timer.c Mon Oct 16 22:31:55 2000
 @@ -201,10 +201,10 @@
         /*
          * 2 MSL timeout in shutdown went off.  If we're closed but
          * still waiting for peer to close and connection has been idle
 -        * too long, or if 2MSL time is up from TIME_WAIT, delete connection
 -        * control block.  Otherwise, check again in a bit.
 +        * too long, or if 2MSL time is up from TIME_WAIT or FIN_WAIT_2,
 +        * delete connection control block.  Otherwise, check again in a bit.
          */
 -       if (tp->t_state != TCPS_TIME_WAIT &&
 +       if (tp->t_state < TCPS_FIN_WAIT_2 &&
             (ticks - tp->t_rcvtime) <= tcp_maxidle)
                 callout_reset(tp->tt_2msl, tcp_keepintvl,
                               tcp_timer_2msl, tp);
 
 -- 
 Ryan "Cheshire" Younce | ryan@manunkind.org | http://www.manunkind.org/~ryan
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010170310.UAA68554>