This is a static archive of our old Q&A Site. Please post any new questions and answers at

Getting TCP RST,ACK and appliction does not handle this well


We have a kit we send for demos which is just a Windows 2008R2 server, 2 Windows 7 clients, and 2 Windows 7 embedded devices all with static IP addresses connected to each other via a dumb switch. The 2 embedded devices send data to the server via sockets with not problem. The server also hosts IIS. I have a .Net application that uses Websync to stream data from the web server to the 2 clients. In this closed network I would see that the stream of data would pause for several seconds every once in a while. Using wireshark I found that at the time of the "pause" the client had sent a TCP [RST, ACK] which made the websync connection wait for its 15 second time out and then everything picked back up again. I have been trying to find an explanation as to why this RST is being sent at all. Sometimes it will go an hour with no reset while other times it will send one once a minute.

Here is a set of frames where there are 3 successful packets and one that fails with the RST. The interesting thing is that the last POST does not show in the IIS logs.

5287    12:46:08.970006000   HTTP    605 POST /webservice/nlogreceiver.svc/binarylogger HTTP/1.1  (application/soap+msbin1)
5288    12:46:08.970397000   TCP 60  http > 50460 [ACK] Seq=2664 Ack=4432 Win=64000 Len=0
5289    12:46:08.973167000   HTTP    558 HTTP/1.1 200 OK  (application/soap+msbin1)
5290    12:46:09.169231000   TCP 54  50460 > http [ACK] Seq=4432 Ack=3168 Win=65536 Len=0
5291    12:46:09.472499000   TCP 242 [TCP segment of a reassembled PDU]
5292    12:46:09.472631000   HTTP    300 POST /websync.ashx?token=37043804&src=dn&AspxAutoDetectCookieSupport=1 HTTP/1.1  (application/json)
5293    12:46:09.472949000   TCP 60  http > 50460 [ACK] Seq=3168 Ack=4866 Win=65536 Len=0
5294    12:46:09.474608000   HTTP    645 HTTP/1.1 200 OK  (application/json)
5295    12:46:09.475156000   TCP 66  50462 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
5296    12:46:09.475523000   TCP 66  http > 50462 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
5297    12:46:09.475607000   TCP 54  50462 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
5298    12:46:09.475730000   HTTP    270 GET /websync.ashx?token=37043804&src=dn&AspxAutoDetectCookieSupport=1 HTTP/1.1 
5299    12:46:09.476687000   HTTP    262 HTTP/1.1 200 OK  (text/html)
5300    12:46:09.483488000   TCP 242 [TCP segment of a reassembled PDU]
5301    12:46:09.483586000   HTTP    949 POST /websync.ashx?token=37043804&src=dn&AspxAutoDetectCookieSupport=1 HTTP/1.1  (application/json)
5302    12:46:09.483800000   TCP 60  http > 50460 [ACK] Seq=3759 Ack=5949 Win=64512 Len=0
5303    12:46:09.485582000   HTTP    606 HTTP/1.1 200 OK  (application/json)
5304    12:46:09.685192000   TCP 54  50462 > http [ACK] Seq=217 Ack=209 Win=65280 Len=0
5305    12:46:09.692156000   TCP 54  50460 > http [ACK] Seq=5949 Ack=4311 Win=64512 Len=0
5306    12:46:09.757194000   TCP 54  50462 > http [RST, ACK] Seq=217 Ack=209 Win=0 Len=0

asked 02 Apr '14, 10:39

Blackadder's gravatar image

accept rate: 0%

can you post the capture at Reading ASCII dumps is not going to work well, especially when tracking TCP stuff.

(02 Apr '14, 11:33) Jasper ♦♦

Ok, I added a new capture here: It is a filtered capture to only include from either the client or server. Client is 104 and server is 90. There are 2 failures. Timestamp 19:14:11.2085 and 19:15:02:8997 This is when I get the stream failure log so the problem occurs some time before this I guess.

(02 Apr '14, 12:44) Blackadder

One Answer:


Hint: the timestamps are not helping since they change depending on the time zone settings of the PC Wireshark is running on. It is usually better to specify packet numbers or TCP stream indexes because they're constant within a capture file.

So far I found a couple of Resets, but none that look problematic from a network point of view. It is quite common these days for IIS and some clients to terminate sessions via reset packet instead of FIN/ACK/FIN/ACK, since it is much faster and frees resources immediately.

In packets 2011 and 2496, the client finishes the connection with a reset after a GET request, receiving the answer and acknowledging it. This looks just like "okay, got it, thanks, bye!", and no foul play.

In packet 2641, it is a little different. For some reason the client waits for 110 seconds this time before sending the reset. Once again, no foul play from a packet point of view, but I guess the client may have encountered something that kept it from closing the connection right away. This conversation is not with the .90 though, but with .101. Maybe a wrong server IP, or just something that got into the capture by mistake?

All other resets are from the server and look pretty normal, too. They look like normal "oh, I guess this connection is not going to be reused again, I waited long enough, so let's close it" packets.

answered 03 Apr '14, 01:30

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%