Re: clarification of CD termination code

[Jeffrey 'jf' Lim]

On Thu, Aug 5, 2010 at 7:29 AM, Bryan Talbot btal...@aeriagames.com 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?

 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



yes - i've encountered this myself, and after looking into the
traffic, observed the very same thing from windows clients...
Definitely frustrating behaviour in terms of causing all these alerts
in the logs...

-jf


--
Every nonfree program has a lord, a master --
and if you use the program, he is your master.
--Richard Stallman

It's so hard to write a graphics driver that open-sourcing it would not help.
-- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228

Re: clarification of CD termination code

[Willy Tarreau]

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