From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 00:37:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D12D916A4CE for ; Tue, 9 Nov 2004 00:37:02 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1755343D3F for ; Tue, 9 Nov 2004 00:37:02 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) iA90awaI094955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 9 Nov 2004 01:36:59 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id iA90Zqsu024073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Nov 2004 01:35:53 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id iA90ZqxC002343 for ; Tue, 9 Nov 2004 01:35:52 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id iA90ZqZX002342 for freebsd-net@freebsd.org; Tue, 9 Nov 2004 01:35:52 +0100 (CET) (envelope-from ticso) Date: Tue, 9 Nov 2004 01:35:52 +0100 From: Bernd Walter To: freebsd-net@freebsd.org Message-ID: <20041109003551.GG98623@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Subject: close_wait state lost? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 00:37:03 -0000 [89]cicely13# tcpdump -n port 502 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tx0, link-type EN10MB (Ethernet), capture size 96 bytes 00:44:07.031278 IP 10.1.1.15.60646 > 10.1.1.245.502: S 428196572:428196572(0) win 65535 00:44:07.048388 IP 10.1.1.245.502 > 10.1.1.15.60646: S 1000000:1000000(0) ack 428196573 win 3216 00:44:07.048837 IP 10.1.1.15.60646 > 10.1.1.245.502: . ack 1 win 65535 00:44:07.050228 IP 10.1.1.15.60646 > 10.1.1.245.502: P 1:7(6) ack 1 win 65535 00:44:07.052560 IP 10.1.1.15.60646 > 10.1.1.245.502: P 7:12(5) ack 1 win 65535 00:44:07.063431 IP 10.1.1.245.502 > 10.1.1.15.60646: . ack 7 win 3210 00:44:07.073372 IP 10.1.1.245.502 > 10.1.1.15.60646: . ack 12 win 3211 00:44:07.084658 IP 10.1.1.245.502 > 10.1.1.15.60646: P 1:7(6) ack 12 win 3216 00:44:07.091685 IP 10.1.1.245.502 > 10.1.1.15.60646: P 7:33(26) ack 12 win 3216 00:44:07.092031 IP 10.1.1.15.60646 > 10.1.1.245.502: . ack 33 win 65535 00:44:07.096082 IP 10.1.1.15.60646 > 10.1.1.245.502: P 12:18(6) ack 33 win 65535 00:44:07.098019 IP 10.1.1.245.502 > 10.1.1.15.60646: F 33:33(0) ack 12 win 3216 00:44:07.099479 IP 10.1.1.15.60646 > 10.1.1.245.502: P 18:23(5) ack 33 win 65535 00:44:07.116718 IP 10.1.1.245.502 > 10.1.1.15.60646: . ack 23 win 3205 ^C 14 packets captured 134 packets received by filter 0 packets dropped by kernel [90]cicely13# netstat -an | grep 502 tcp4 0 0 10.1.1.15.60646 10.1.1.245.502 ESTABLISHED The server is running Ethernut Nut/OS and does a close on the connect after each transaction for sparse resource reasons. The client was a month old 6.0-current (also verified with a march 5.2-current). The client application establishes a new connection, enables TCP_NODELAY and tries to cache the connection. It does two write(2) (6 byte then 5 byte in the above case) calls and then 2 read(2) calls for each transaction. The first transaction wents fine with the fresh connection. Normaly the client should notice the dropped connection and reconnect, but instead succeds in both write calls. The client is then stuck in the first read(2) call. I would have expected at least the read to fail, because this one waits for either data or connection drop. But also the server already had send a FIN it does ack a data packet later and I see the connection as established under netstat. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de