From owner-freebsd-current Thu Nov 4 17:30:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 00D2E14F59 for ; Thu, 4 Nov 1999 17:30:37 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id TAA04858; Thu, 4 Nov 1999 19:28:49 -0600 (CST) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.8.5/8.6.4) with ESMTP id TAA27568; Thu, 4 Nov 1999 19:28:49 -0600 (CST) Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id PAA20756; Thu, 4 Nov 1999 15:44:45 -0600 (CST) Date: Thu, 4 Nov 1999 15:44:45 -0600 (CST) From: Jonathan Lemon Message-Id: <199911042144.PAA20756@free.pcs> To: ken@kdm.org, current@freebsd.org Subject: Re: TCP sockets stuck in the CLOSING state X-Newsgroups: local.mail.freebsd-current In-Reply-To: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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''). 14:55:49.142607 folly.56982 > cache.9000: S 1691420120:1691420120(0) win 16384 (DF) 14:55:49.142663 cache.9000 > folly.56982: S 1946461253:1946461253(0) ack 1691420121 win 17520 (DF) 14:55:49.142991 folly.56982 > cache.9000: . ack 1 win 17520 (DF) 14:55:49.143384 folly.56982 > cache.9000: P 1:188(187) ack 1 win 17520 (DF) 14:55:49.340283 cache.9000 > folly.56982: . ack 188 win 17520 (DF) 14:55:50.287660 cache.9000 > folly.56982: P 1:1442(1441) ack 188 win 17520 (DF) 14:55:50.484537 cache.9000 > folly.56982: . 1442:2902(1460) ack 188 win 17520 (DF) 14:55:50.484552 cache.9000 > folly.56982: P 2902:4362(1460) ack 188 win 17520 (DF) 14:55:50.490171 cache.9000 > folly.56982: P 4362:4781(419) ack 188 win 17520 (DF) 14:55:50.490369 cache.9000 > folly.56982: F 4781:4781(0) ack 188 win 17520 (DF) 14:55:50.492154 folly.56982 > cache.9000: . ack 4781 win 17520 (DF) 14:55:50.492160 folly.56982 > cache.9000: F 188:188(0) ack 4781 win 17520 (DF) 14:55:50.492229 cache.9000 > folly.56982: . ack 189 win 17520 (DF) 14:55:51.490279 cache.9000 > folly.56982: . ack 189 win 17520 (DF) Note that I think there are at least two oddities here: 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. 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). Both machines are running -current from early this week. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message