Date: Tue, 9 Nov 2004 15:30:55 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: freebsd-net@freebsd.org Subject: Re: close_wait state lost! Message-ID: <20041109143054.GI98623@cicely12.cicely.de> In-Reply-To: <20041109003551.GG98623@cicely12.cicely.de> References: <20041109003551.GG98623@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 09, 2004 at 01:35:52AM +0100, Bernd Walter wrote: > [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. I think this is a bug in FreeBSD somewhere. The write calls suceeding and the acking of them by the server is OK, because we still have a half closed connection. But it is not OK for FreeBSD to loose the information about the close_wait state and therefor block in the read call. -- 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?20041109143054.GI98623>