Date: Mon, 16 Oct 2000 20:20:03 -0700 (PDT) From: Ryan Younce <ryan@manunkind.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/21791 Message-ID: <200010170320.UAA71836@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.FreeBSD.ORG
Cc:
Subject: Re: kern/21791
Date: Mon, 16 Oct 2000 23:13:33 -0400 (EDT)
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 Younce / Registered Libertarian Voter | The notion of a 'record' is
ryan@manunkind.org www.manunkind.org/~ryan/ | an obsolete remnant of the
ICQ H:4433228 W:74390437 AIM:CheshireCoolCat | days of the 80-column card.
Blitherings: http://cheshire.livejournal.com/ | -- Dennis M. Ritchie
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.UAA71836>