5

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!

2 Answers 2

3

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.

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

1
  • thanks. i did not put it clearly, but my main problem is that the client application from time to time did not 'notice' that the connection is being closed bu the server and waits, eventually times out.
    – pQd
    Dec 14, 2013 at 8:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .