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. asked 02 Apr '14, 10:39  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 ♦♦ |
can you post the capture at http://www.cloudshark.org? Reading ASCII dumps is not going to work well, especially when tracking TCP stuff.
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.