This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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

asked 02 Apr '14, 10:39

Blackadder's gravatar image

Blackadder
11112
accept rate: 0%

can you post the capture at http://www.cloudshark.org? 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: https://www.cloudshark.org/captures/f5a062ccfdf6 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

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.

permanent link

answered 03 Apr '14, 01:30

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×1,620
×293
×248
×81

question asked: 02 Apr '14, 10:39

question was seen: 7,451 times

last updated: 03 Apr '14, 01:30

p​o​w​e​r​e​d by O​S​Q​A