On Wed, Aug 04, 2010 at 04:29:08PM -0700, Bryan Talbot wrote: > In the tcpdump listed below, isn't the next-to-the-last RST also include an > ACK of the data previously sent? If that is the case, then the client has > received all of the data and ACK'd it but then rudely closed the TCP > connection without the normal FIN exchange. Is my reading correct?
Yes, that looks like it, though the RST's ACK does not seem to cover the FIN (otherwise it would be 271). While "rude", doing this is unfortutenately necessary when the client has to close the connection itself, otherwise if it closes cleanly, it will be subject to the 2-MSL TCP delay which prevents it from reusing the same source port for a few minutes. So closing that way ensures that the connection is aborted and that the port can be reused ASAP. If you take a trace between a haproxy and a server when haproxy is configured with "option forceclose", you will see the same termination sequence. BTW, for better traces, you should use the '-S' option with tcpdump, so that it does not try to use relative sequence numbers, because here we have a mix of absolute and relative, which is harder to read. > 19:03:33.106842 IP 10.79.25.20.4266 > 10.79.6.10.80: S > 2041799057:2041799057(0) win 65535 <mss 1460,nop,nop,sackOK> > 19:03:33.106862 IP 10.79.6.10.80 > 10.79.25.20.4266: S 266508528:266508528(0) > ack 2041799058 win 5840 <mss 1460,nop,nop,sackOK> > 19:03:33.106945 IP 10.79.25.20.4266 > 10.79.6.10.80: . ack 1 win 65535 > 19:03:33.107045 IP 10.79.25.20.4266 > 10.79.6.10.80: P 1:269(268) ack 1 win > 65535 > 19:03:33.107060 IP 10.79.6.10.80 > 10.79.25.20.4266: . ack 269 win 6432 > 19:03:33.134401 IP 10.79.6.10.80 > 10.79.25.20.4266: P 1:270(269) ack 269 win > 6432 > 19:03:33.134442 IP 10.79.6.10.80 > 10.79.25.20.4266: F 270:270(0) ack 269 win > 6432 > 19:03:33.134548 IP 10.79.25.20.4266 > 10.79.6.10.80: R 269:269(0) ack 270 win > 0 > 19:03:33.134562 IP 10.79.25.20.4266 > 10.79.6.10.80: R > 2041799326:2041799326(0) win 0 > > > -Bryan Regards, Willy
