Date: Tue, 9 Nov 2004 01:35:52 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: freebsd-net@freebsd.org Subject: close_wait state lost? Message-ID: <20041109003551.GG98623@cicely12.cicely.de>
next in thread | raw e-mail | index | archive | help
[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 <mss 1460,nop,nop,sackOK,nop,wscale 1,nop,nop,timestamp 82175655 0> 00:44:07.048388 IP 10.1.1.245.502 > 10.1.1.15.60646: S 1000000:1000000(0) ack 428196573 win 3216 <mss 536> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041109003551.GG98623>