Hi, I'm having an issue with some vendor software, but it appears to be more closely related to the way the TCP/IP stack is handling session shutdown. I'd like to know what this feature is called, any available documentation, and ideally how to disable it. Basically, what appears to happen, is Server 2008 is sending a Rst, Ack to terminate a short lived connection, instead of entering the standard TCP shutdown (Using FIN flags). This appears to be an attempt to avoid having short lived sessions sit in a TIME_WAIT state, as I can see long TCP connections properly being shutdown. I realize the benefits of what this is trying to accomplish, however, the software in question is making HTTP calls, and the server being rather basic, is sending HTTP responses without content-length or transfer encoding: chunked, which means the only way to tell the server is done sending content is for the connection to close. However, it appears that the stack is interpreting this type of Tcp shutdown as in error, and generating annoying alerts within the application that is monitoring the close state. Does windows have a way to disable this stack feature. I've confirmed the chimney offload doesn't appear to be in use, so this is an effect of the Windows stack itself. I don't have control of the software on either end, but do have a bug open with the vendor, I'm more interested in a possible workaround for the short term. ** Entire connection lasts ~1 second Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 0, Len: 0 Flags: 0x02 (SYN) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 0, Ack: 1, Len: 0 Flags: 0x12 (SYN, ACK) Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 1, Ack: 1, Len: 0 Flags: 0x10 (ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1, Ack: 2921, Len: 0 Flags: 0x10 (ACK) Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 2921, Ack: 1, Len: 1234 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1, Ack: 4155, Len: 57 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 58, Len: 0 Flags: 0x10 (ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 58, Ack: 4155, Len: 1024 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1082, Ack: 4155, Len: 1460 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 2542, Len: 0 Flags: 0x10 (ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 2542, Ack: 4155, Len: 1460 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 4002, Ack: 4155, Len: 1460 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 5462, Ack: 4155, Len: 1460 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 6922, Ack: 4155, Len: 1081 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 8003, Len: 0 Flags: 0x10 (ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 8003, Ack: 4155, Len: 1460 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 9463, Ack: 4155, Len: 108 Flags: 0x18 (PSH, ACK) Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172) Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 9571, Len: 0 Flags: 0x10 (ACK) Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231) Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 9571, Ack: 4155, Len: 0 Flags: 0x14 (RST, ACK)

I'm having a similar issue with an XP machine (which allows users to RDP to it) abruptly terminating RDP connections. It automatically re-connects after a few seconds. 100703 15:21:44.820058 10.49.9.205 10.49.8.60 TCP ms-wbt-server > orasrv [RST, ACK] Seq=20515531 Ack=26977 Win=0 Len=0 100873 15:22:11.148594 10.49.9.205 10.49.8.60 TCP ms-wbt-server > orasrv [RST] Seq=20513010 Win=0 Len=0 I'm just trying to understand why this happens, so I know where to start looking. Thanks!

Hi KNisbet, You mention chimney offload not in use on your server. Please use command "netsh int tcp show global>tcp.txt" to show your setting. Please try to use command below one by one on your server. netsh int tcp set global chimney=disabled netsh int tcp set global RSS=disabled netsh int tcp set global autotuninglevel=disabled If there are more inquiries on this issue, please feel free to let us know.Regards, Rick Tan

Rick, this did not help as it's the approach i've already taken in testing. Albeit, I did disable the chimney offload on the NIC drivers instead of the windows options, but in the wireshark captures I'm still seeing the same behavior. Humand, I don't think you're issue is the same as mine, I beleive these RST, ACK's are in response to a NORMAL connection shutdown, and being interpretted as errors be the partner stack. I haven't seen this cause premature tcp shutdown, which would be you're dropped RDP connections. TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : disabled Chimney Offload State : disabled NetDMA State : enabled Direct Cache Acess (DCA) : disabled Receive Window Auto-Tuning Level : disabled Add-On Congestion Control Provider : ctcp ECN Capability : disabled RFC 1323 Timestamps : disabled

Hi KNisbet, Thank you for your question. I am currently looking into this issue and will give you an update as soon as possible. Thank you for your understanding and support.Regards, Rick Tan

Hi KNisbet, My name is Scott. I'm from Microsoft network email support team. I know your concern is that the server sends Reset packet instead of Finish packet to terminate the connection. You want to know if there is a way to disable any feature on windows to prevent it from sending Reset packet. However, the server's behavior is normal and it depends not on windows but on the application. In some instances, the application developers elect to issue a Reset instead of Finish to free up resources more quickly for waiting users. It will skip the time wait status for the termination procedure. I attach an article about it for your reference: http://support.microsoft.com/kb/272933 Regards, Scott Xie