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

Spurious Retransmission RST,ACK

0

We are experiencing an issue when uploading a file to a sFTP server. Most of the time the upload is a success, however occasionally it fails. Running Wireshark we discovered we are sending a SYN frame and receiving a RST,ACK seemingly from destination (but I have doubts about that). Looking at the failed trace I see where we try and establish connection multiple times before giving up. One thing I note as odd is the response time between frames, they're approximately 0.000733 seconds on the failed connection. For the successful connection the response times are approximately 0.031923 seconds. I've included a screenshot of both the failure and success.

Notes

  • When this occurs we can usually correct it by logging into the source server via RDP and it instantly begins working.
  • We've moved this process to another source server but continue to have the problem.
  • I'm not seeing any of this traffic in my ASA
  • Source: Windows 2012 R2 (We also tried running on Windows 2008 R2)
  • I have no control over destination, furthermore they have told me we are the only ones with this problem

Failure Screenshot Failure Screenshot

Success Screenshot Success Screenshot

Network Topology

[ Source Server ] ---- [ Web Filter (only port 80) ] ---- [ ASA w/ IPS Module ] ---- [ Link Balancer ] ---- [ Internet ] ---- [ Destination]

asked 30 Jul '15, 05:19

tlpitch's gravatar image

tlpitch
6112
accept rate: 0%

I noticed the ECN flag as well and thought that could be the issue, however it is something that MS enabled in Windows 2012. We're running this process on a Windows 2008 box at the moment and the Wireshark during the failures shows it is not present. Additionally I have traces that show successful connection with ECN enabled.

I like you thought the same thing, so upon researching I found that I could disable ECN but that didn't help on the Windows 2012.

When we are having failures I've run traces from the ASA and I don't see any traffic during the times where we have a failure.

ECN http://serverfault.com/questions/526377/is-ecn-explicit-congestion-notification-turned-on-by-default-on-windows-server

(30 Jul '15, 12:47) tlpitch

Can you provide the following outputs?

netsh int tcp show global output?

And the following Powershell displays at the Win2012.

Get-NetAdapter
Get-NetAdapterAdvancedProperty
Get-NetAdapterHardwareInfo
Get-NetTCPSetting

If you say, that you have succesfull traces with a ECN inside, do you mean to that sFTP server?

(30 Jul '15, 13:01) Christian_R

I've included two server outputs. The 2008 is the one the application folks move the process for testing. The 2012 box is the one we started using and ultimately wish to use- both produce the same failures.

On the Windows 2008 (the current system) TCP Global Parameters


Receive-Side Scaling State : enabled Chimney Offload State : automatic NetDMA State : enabled Direct Cache Acess (DCA) : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : ctcp ECN Capability : disabled RFC 1323 Timestamps : disabled

On the Windows 2012 (the desired system) TCP Global Parameters


Receive-Side Scaling State : enabled Chimney Offload State : disabled NetDMA State : disabled Direct Cache Access (DCA) : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : none ECN Capability : disabled RFC 1323 Timestamps : disabled Initial RTO : 3000 Receive Segment Coalescing State : enabled Non Sack Rtt Resiliency : disabled Max SYN Retransmissions : 2

(30 Jul '15, 13:13) tlpitch

maybe you have to set the congestion control provider to ctcp like the win2008

(31 Jul '15, 01:25) Christian_R

One Answer:

0

Hi I can´t remember that I have seen a packet like Frame #7, (SYN,ECN,CWR) and maybe your FW/IPS eitehr not. So if I were you, I would take a trace at the last point of my network, so that I can see if the packet left my network correctly.


Edit:

Ok at least I found that the Syn in frame 7 is correct see here: https://tools.ietf.org/html/rfc3168

Also it can be seen that Frame 7 starts with rfc3168 feature than goes back to to rfc1323 and ends in the old tcp syn request. This is like an normal behaviour. So I guess that the most probable cause for the failure is in or next to your FW or IPS (Maybe it is a bug of this device)


See similar question here: https://ask.wireshark.org/questions/29758/syn-with-ecn-flag-set-on-certain-port-number

answered 30 Jul '15, 11:52

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%

edited 31 Jul '15, 01:22