Home / server / Questions / 561241
Accepted
pQd
Asked: 2013-12-14 11:02:15 +0800 CST

once in a while windows / .net application ignores the tcp fin flag

  • 772

i've run into a network problem which i cannot solve. on a few computers running windows 8.1 and communicating with linux http server tcp connections dangle on the windows side instead of being properly closed.

after response [fragmented into few, acknowledged by windows, tcp packets] linux server - 10.14.11.59 - sends a tcp packet containing FIN and ACK flags set. enter image description here

this is acknowledged by the windows machine - 10.14.10.195 - with packet having only the ACK flag set. enter image description here

linux re-sends packets with FIN and ACK flags few times while windows machine - for some reason still keeps the connection open; packets with the RST flag are never sent by the windows machine. enter image description here

if that happens windows application waits and eventually times out. this happens randomly somewhere between 10-50% of attempts.

traffic between both machines is unfiltered; host-based firewalls were off. to avoid potential problems i've disabled tcp offloading on on linux, and windows. additionally on windows the following were run and machine was rebooted:

netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global rss=disabled

packet capture: here.

any thoughts will be appreciated!

tcp

2 Answers

  1. Best Answer

    we've found out that eset endpoint security running on the client machines was the culprit.

    disabling the firewall functionality was not enough; but uninstalling it completely resolved the problem.

    my colleagues found description of a similar issue here; apparently upgrade to the latest version of eset resolved the problem as well.

    • 3

  2. I assume that the first segment in your tcpdump is preceded by a FIN from the client.

    I believe this is correct client behavior, as illustrated by this ASCII diagram from the original RFC

    A closing client, upon receiving a FIN,ACK from the server, the socket transitions from FIN-WAIT1 to TIME-WAIT and remains in this state for 2 times Maximum Segment Lifetime in the network, at which point it sends a FIN back, to close the connection.

    Windows overrides the TIME-WAIT duration with a registry value name TcpTimedWaitDelay, originally implemented with a default value of 240 seconds (MSL defaults to 120 seconds). In Windows XP/Server 2003 and above, the default value is lowered to 120 seconds.

    I believe you can solve this by closing the underlying socket on the server when you've served the response, but be sure to read this answer as well, to roughly the same question, but from a server perspective

    • 2