close_wait state lost!

[Bernd Walter]

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 at bwct.de                                  info at bwct.de