From owner-freebsd-current Sun Nov 7 6:14:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id DF47114F6D for ; Sun, 7 Nov 1999 06:14:08 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id JAA77246; Sun, 7 Nov 1999 09:14:00 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <199911071414.JAA77246@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dag-Erling Smorgrav Cc: "Kenneth D. Merry" , jlemon@americantv.com (Jonathan Lemon), current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: TCP sockets stuck in the CLOSING state References: <199911052219.PAA01743@panzer.kdm.org> In-reply-to: Your message of "07 Nov 1999 13:41:48 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 07 Nov 1999 09:14:00 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > "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). I think your interpretation of the TCP spec is in error. Since the FIN occupies sequence space, it's the same as unacknowledged data and should be retransmitted, just like any unacked data in the window would be. Eventually, the TCP stack should timeout the connection with an ACK-timeout. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message