Hi, We are having a very weird issue that has been going on for a number of months on our network. We currently have a 3 Windows Server 2003 servers that have connectivity issues between them. We have a .Net app that monitors a folder via a network share on another server and the .net app seems to hang periodically for about 33 seconds. I've downloaded and installed Wireshark and I can find what I believe the problem packets however I can't understand why this is happening. Here is a copy/paste from our wireshark capture: 44133 2013-02-21 10:27:34.948610000 408.427221000 53.248.98.58 53.248.98.60 TCP 54 appworxsrv > microsoft-ds [ACK] Seq=18552 Ack=39734 Win=65077 Len=0 44693 2013-02-21 10:28:08.416593000 441.895204000 53.248.98.58 53.248.98.60 TCP 54 appworxsrv > microsoft-ds [FIN, ACK] Seq=18552 Ack=39734 Win=65077 Len=0 44694 2013-02-21 10:28:08.416658000 441.895269000 53.248.98.60 53.248.98.58 TCP 60 microsoft-ds > appworxsrv [FIN, ACK] Seq=39734 Ack=18553 Win=65283 Len=0 44695 2013-02-21 10:28:08.416670000 441.895281000 53.248.98.58 53.248.98.60 TCP 54 appworxsrv > microsoft-ds [ACK] Seq=18553 Ack=39735 Win=65077 Len=0 If you look at the time between 44133 and 44693 this is where the time delay is occuring but I don't know why. Any ideas or help would be appreciated. Kevin asked 21 Feb '13, 10:59  KPMoore |
One Answer:
I doubt that the packets you have quoted are a cause for your delay. What you have is a packet coming from 53.248.98.58 with no payload (Len=0), so there is no need for 53.248.98.60 to acknowledge it. Then, we again see a packet from 53.248.98.58, which is about 34 seconds late, but it is a FIN packet, tearing down the connection from this side. That ususally happens when a node realizes that the TCP session is not needed for any more data transfers and torn down - a typical and quite normal time out trigger. The rest is just the usualy FIN-ACK-FIN-ACK procedure, so nothing special there, either. By that time, the application has to have all the data it needs, otherwise there would not be a FIN-ACK teardown. I agree that the delay of 34 seconds is curious since you said that it is about the time your transfer hangs, but you should probably look for the reason in another place. What you need to look for are data packets that are either sent out with a delay instead of right away, or the same for late arrival of acknowledges that slow down the sender's performance. answered 21 Feb '13, 13:13  Jasper ♦♦ |
Jasper,
Thank you for your analysis. This issue has me quite stumped and I'll go back and review the wireshark log to see if there are any other packets that could indicate a problem and I'll post a follow up in a bit.
Thanks, Kevin