From owner-freebsd-current Sun Nov 7 4:41:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 568E614FDE; Sun, 7 Nov 1999 04:41:52 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA13458; Sun, 7 Nov 1999 13:41:48 +0100 (CET) (envelope-from des) To: "Kenneth D. Merry" Cc: jlemon@americantv.com (Jonathan Lemon), current@freebsd.org Subject: Re: TCP sockets stuck in the CLOSING state References: <199911052219.PAA01743@panzer.kdm.org> From: Dag-Erling Smorgrav Date: 07 Nov 1999 13:41:48 +0100 In-Reply-To: "Kenneth D. Merry"'s message of "Fri, 5 Nov 1999 15:19:41 -0700 (MST)" Message-ID: Lines: 61 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [bringing this back to -current, with a Bcc to -security] "Kenneth D. Merry" writes: > Jonathan Lemon wrote... > > In article 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