Date: 07 Nov 1999 13:41:48 +0100 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: "Kenneth D. Merry" <ken@kdm.org> Cc: jlemon@americantv.com (Jonathan Lemon), current@freebsd.org Subject: Re: TCP sockets stuck in the CLOSING state Message-ID: <xzpogd61njn.fsf@flood.ping.uio.no> In-Reply-To: "Kenneth D. Merry"'s message of "Fri, 5 Nov 1999 15:19:41 -0700 (MST)" References: <199911052219.PAA01743@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[bringing this back to -current, with a Bcc to -security] "Kenneth D. Merry" <ken@kdm.org> writes: > Jonathan Lemon wrote... > > In article <local.mail.freebsd-current/199911042000.NAA91632@panzer.kdm.org> you write: > > > Before I spend a lot of time hunting this down, I figured it might be worth > > > asking -- is there any particular reason why TCP sockets may be getting > > > stuck in the CLOSING state more often now? > > Not sure. But here's a tcpdump trace of a socket that ends up in the > > CLOSING state. (on the host ``cache''). > > [...] > > 1. the other end (folly) never acks the FIN. The packets at > > timestamp .492154 and .492160 do not cover the FIN in the > > sequence space. Yet the host `folly' closes the socket. This is weird, and probably deserves some investigation (at least if cache and folly are on the same LAN; otherwise there's a non-zero possibility of the ACK simply getting lost on the way) > > 2. the end that is stuck in CLOSING (cache) never retransmits > > the FIN. (The tcpdump extends for about 5 minutes after the > > last packet, with 0 packets lost). It's not supposed to (according to RFC793). > > Both machines are running -current from early this week. > > Those are definitely odd. > > After looking through the changes since June, I think (and DES seems to > agree) that the problems are most likely in your timeout code from August. > Most every other change in the TCP stack has been cosmetic, or #ifdefed, so > it wouldn't be enabled by default. > > He is going to try to find the problem, although it's most likely a pretty > subtle bug. Well, the TCP state machine was never a fun read, amd I haven't had time to look very closely at the problem yet, but it seems that there is no way for a connection to leave the TCPS_CLOSING state other than the receipt of an ACK matching a previously sent FIN. If the ACK gets lost, the connection is stuck in TCPS_CLOSING forever (I have a connection that's been stuck in TCPS_CLOSING for at least three days now). The only instance I can find where a connection in TCPS_CLOSING state is closed even if no ACK has been received is when the socket has the SO_KEEPALIVE option set (tcp_timer_keep() in tcp_timer.c). Note that the state transition diagram in RFC793 does not specify a timeout for the CLOSING -> TIME_WAIT transition, so any faithful implementation of RFC793 has this bug (but why doesn't this happen on -STABLE, or on pre-August -CURRENT?) This hints at a potential DoS vulnerability. Hack a TCP stack to never acknowledge FIN segments, and blast away at your victim; chances are he'll run out of mbufs before you run out of source ports (each source port can only be used once in the attack). Give me a few hours and I might be able to verify this vulnerability experimentally. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpogd61njn.fsf>