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>
index | next in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010170320.UAA71847>