FTP transfer resetting every 10m30s with code 1292

Alexander Lindberg 1 Reputation point

We've been banging our heads against the wall for this one.

Using IIS 10 on Server 2016, we are seeing a repeatable issue with ftp transfers from a single remote client. 10 minutes and 30 seconds into the transfer, give or take a second, the connection is reset by IIS:

2022-03-22 06:26:48 xxx.xxx.xxx.163 57650 domain\user - xxx.xxx.xxx.141 36501 DataChannelOpened - - 0 0 1d18eadc-2036-4be3-8846-aef1eec2e8c8 - -
2022-03-22 06:37:18 xxx.xxx.xxx.163 57650 domain\user - xxx.xxx.xxx.141 36501 DataChannelClosed - - 1292 0 1d18eadc-2036-4be3-8846-aef1eec2e8c8 - -
2022-03-22 06:37:18 xxx.xxx.xxx.163 57620 domain\user - xxx.xxx.xxx.141 21 ControlChannelClosed - - 1292 0 1d18eadc-2036-4be3-8846-aef1eec2e8c8 - -
2022-03-22 06:37:19 xxx.xxx.xxx.163 57620 domain\user - xxx.xxx.xxx.141 21 STOR /Output/A_Large_File.tmp 425 1236 0 1d18eadc-2036-4be3-8846-aef1eec2e8c8 /Output/A_Large_File.tmp -

This is repeated either until the transfer is complete (if resume is allowed), or the connection has been reset five times upon which the remote side treats the transfer as failed and stops retrying. This unfortunately can be a problem as we are receiving high bitrate video content which regularly would need more connection attempts.

1292 is a sc-win32-status code, ERROR_IMPLEMENTATION_LIMIT, with the description "An operation attempted to exceed an implementation-defined limit." Unfortunately, no substatus code is provided to give further info on what that implementation limit would be.

For the aborted STOR command, 425 = "Can't open data connection" and 1236 = ERROR_CONNECTION_ABORTED, "The network connection was aborted by the local system."

I find it interesting that the sc status is 425 and not 426 (connection aborted), would this indicate that the initial data connection was never opened properly and that this is what is timing out?

I've done a network trace and compared it to two similar transfers from clients under my control, trying as close as possible to mimic the connection preferences but I can't find anything that would suggest that the handshake process is not setup properly. The only thing that stands out is that the problematic transfer is littered with segments out of order (Wireshark reporting "Encrypted Alert, Ignored Unknown Record"), around 3500 compared to 20 and 50 for my test transfers. Don't know if this indicates something but I find it unlikely since the problem is so tightly tied to the duration of the transfer. It is also not unexpected since there's quite a distance to the remote client compared to those under my control, and the sequences would be reordered and assembled before IIS sees them anyway if I understand everything correctly.

I've only seen a single mention of the same problem, but it is the exact same one:

Anyone has a clue to what this might be, or can help me troubleshoot further?

Best regards

Internet Information Services
{count} votes