I am testing a TCP proxy with some Windows file servers and clients. A few clients machines, including Windows 7, Windows Vista and Windows XP are connected to some windows 2008 server through a TCP proxy. Like this: clients - - - - proxy - - - - servers- - - - = ethernet connection In the tests, the clients will do a lot of read/write to shared folders in the servers. However, when under heavy workload, the clients will reset the TCP connection. After that the clients will re-establish the TCP connection and send a SMB negotiate command to the server. However, immediately after the command is sent, the client will send a TCP reset packet to kill the connection. This process will repeat for about 5 seconds. After that the clients will stop sending reset and the test can continue. I have no idea why the client would reset the connection immediately before the server responds anything. I have checked the event viewer but nothing special could be found. Are there any ways to find out the reason of the TCP reset? Thank you very much.

Hi xtwochu, Thanks for posting here. May I know how did we implement the TCP proxy in this scenario ? which TCP proxy service software we are using now? will it also occur if directly connects to server without proxy or with other protocols instead the SMB ? Where do resets come from? (No, the stork does not bring them.) http://blogs.technet.com/b/networking/archive/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them.aspx Thanks. Tiger LiPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Tiger, Thank you very much for your information. The proxy is a linux server bridging the clients and the servers. The incoming packets are redirected to a local process. The process will then do security checking to the SMB commands and may change the content of the commands. Lastly the packets will be resent to its original destination. Thank you for sharing the informative article. In my scenario, the first reset occurred after tens of thousands of packets were exchanged in the connection, so it is unlikely to be caused by "SMB Reset", "Ack, Reset" and "Port re-use". Before the reset, there isn't any packet retransmissions, so it is unlikely to be "TCP Reset due to no response". The remaining possibilities are "It Came From the Network" and "Application Reset". I checked the MAC address of the reset packet to trace the source of the packet. I found that the reset was really sent from a client. Therefore, I think it is likely that it is an "Application Reset". Is it analysis reasonable? If yes, are there any way to find out why the application, i.e. the SMB client, reset the connection? Thank you very much! xtwochu

Hi xtwochu, Thanks for update. All clients (Windows XP or Windows Vista,7) with same configurations were encountered same issue ? We can take look the methods in the article below If can confirm this issue was caused by application on client side. Control of Winsock Tracing http://msdn.microsoft.com/en-us/library/windows/desktop/bb892100(v=vs.85).aspx Thanks. Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Tiger, Thank you very much for your information. I have enabled the log and will run the test again. I found another problem in one of the Windows 7 client that there are a lot of connections stuck at the TIME_WAIT state. I don't know if this problem is relevant so I would report this problem to this thread: http://social.technet.microsoft.com/Forums/en-US/winserverPN/thread/4f24be04-58b7-413f-9c76-89d61fd0f54b Thanks. xtwochu