Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Oct 2000 20:20:04 -0700 (PDT)
From:      Ryan Younce <ryan@manunkind.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/21791: Hang on FIN_WAIT_2
Message-ID:  <200010170320.UAA71847@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
Cc:  
Subject: Re: kern/21791: Hang on FIN_WAIT_2
Date: Mon, 16 Oct 2000 23:19:04 -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
 therewith 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,210 ****
         /*
          * 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.
          */
 !       if (tp->t_state != TCPS_TIME_WAIT &&
             (ticks - tp->t_rcvtime) <= tcp_maxidle)
                 callout_reset(tp->tt_2msl, tcp_keepintvl,
                               tcp_timer_2msl, tp);
 --- 201,210 ----
         /*
          * 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 or FIN_WAIT_2,
 
 !        * delete connection control block.  Otherwise, check again in a
 bit.
          */
 !       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 Younce         ryan@manunkind.org         http://www.manunkind.org/~ryan
 "B can be thought of as C without types; more accurately, it is BCPL squeezed
  into 8K bytes of memory and filtered through Thompson's brain."
                   --Dennis Ritchie, "The Development of the C Language", 1993
 
 
 
 


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?200010170320.UAA71847>