RadAsyncUpload and TCP Zero Window

[Richard]

Good afternoon,

I'm currently running Telerik UI for ASP.NET AJAX R3 2023.  I am using the RadAsyncUpload with a AsyncHandler.ashx to copy the file to a RadUploadTemp on a file share.

This has been working perfectly for ages but recently large file updates have been failing e.g. a 2.1 GB file failing at 61%.  I'm being told this is due to a TCP Zero Window issue.

I assumed the chunked upload mechanism mitigates the issues caused by TCP window size restrictions, which can cause slowdowns or failures when uploading very large files in a single request. I am setting the upload ChunkSize value to 4194304.

I have the following settings in web.config:

  <system.web>    
    <httpRuntime maxRequestLength="2097151" executionTimeout="18000"/>
  </system.web>

  <system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxAllowedContentLength="4294967295"/>
      </requestFiltering>
    </security>
  </system.webServer>

Have you got any ideas as to why it might be failing for larger files, or what I can do to the configuration to prevent the TCP Zero Window error by pausing data transmission until the receiver is ready to accept more data?

Kind regards,

Richard

[Rumen]

Hi Richard,

Based on your findings and the behavior you described, I can confirm your logic is correct: if RadAsyncUpload were injecting any malicious or Log4j-related payloads, the Snort rule would likely block the very first chunk of the upload, not a later one such as the 45th. RadAsyncUpload streams the file content exactly as it is received from the client, without modifying or injecting any data into the payload. The control is built on ASP.NET AJAX and does not use Java or Log4j libraries at any point.

Key Points:

• No Injection by RadAsyncUpload: The control does not introduce or embed any Log4j or similar signatures into the uploaded files. It simply passes the file data in chunks as received.
• Chunk-Based Blocking: The fact that different SQL Server backup files are blocked at different chunks strongly suggests that the file content itself is triggering the Snort IPS rule. This can happen if a particular byte sequence within the file coincidentally matches the pattern the IPS is designed to detect, even if the file is benign.
• False Positives: While there are no reported false positives for this specific Snort rule, it's not uncommon for large binary files (like SQL Server backups) to contain byte patterns that unintentionally match IPS signatures.

Next Steps:

• To further confirm, you can try uploading other large, non-backup files to see if the issue persists. If only SQL Server backups are affected, it's almost certain the file content is the cause.
• Consider working with your security team to either whitelist this upload path or file type, or adjust the Snort rule to prevent unnecessary blocking of legitimate uploads in this scenario.
• As an additional test, you can try setting DisableChunkUpload="true" on the RadAsyncUpload control. This will send the file as a single request rather than splitting it into chunks. If the upload completes successfully with chunking disabled, it would confirm that the chunked transfer encoding or chunk boundaries are contributing to the Snort detection. If the same signature still triggers, it is more likely that the file content alone is responsible.
  

Regards,
Rumen
Progress Telerik

[Richard]

Hi Rumen,

Thanks for your really helpful answer, and suggestions for next steps.

The problem only exists with some SQL Server backups - some upload successfully, others trigger the Snort rule.

I tried running the upload with DisableChunkUpload="true". The upload failed at exactly the same point as when the file is split into chunks - the % transferred is the same whether DisableChunkUpload is true or false.

Seeing as this seems to confirm it is the file content that's causing the Snort rule violation, I'm going to request a meeting with the team that administers the network gateway to see if they will whitelist upload path - this sounds the easiest solution as all chunked uploads will initially go to the same network folder.

Many thanks again for your assistance.

Richard

[Hester]

Hello @ brawl stars online, 

Your chunk size of 4194304 bytes (approximately 4 MB) is reasonable, but you might want to experiment with smaller chunk sizes, especially if the network is unstable or if the server has a limited ability to process large data chunks. Try reducing the chunk size to 1048576 bytes (1 MB) to see if it improves upload stability. Moreover, I think you should ensure that the timeout settings are sufficient for large uploads. You can try increasing the executionTimeout in your web.config further, though it seems you already have it set quite high (18000 seconds).

[Richard]

Hi Hester,

Many thanks for your reply.

I've tried different chunk sizes (1 MB, 2 MB and 8 MB) but ultimately it gets to the same point where approximately 170 MB has been transferred in 20-30 minutes and the transfer halts.

Increasing the executionTimeout won't help as it's set to 5 hours and we're seeing problems much earlier than that.

Is there anything else I can try, or do you think this problem is being caused by the network?  There are a couple of gateways on the network so it's possible one of those is causing the drop in the TCP connection.

Kind regards,

Richard

[Rumen]

Hi Richard,

Since the RadAsyncUpload implementation hasn't changed and you're seeing issues only with large files after a long transfer duration, it’s very likely that the problem is related to network throughput, file I/O bottlenecks, or resource exhaustion rather than the upload control itself.

Here are several steps and considerations that might help pinpoint and resolve the TCP Zero Window issue:

Isolate the Destination Bottleneck

• Try writing to a local folder instead of the network file share (RadUploadTemp). If the upload succeeds, it strongly suggests that the file share (or its network path) is introducing latency or blocking writes during large uploads.
• Exclude the upload folder from antivirus scanning, especially if you are using real-time protection tools. These can interfere with large or partial files during write operations.

Investigate Network and Gateway Behavior

• Check your gateway configuration: If your setup involves reverse proxies, load balancers, or other intermediaries, verify that they are not imposing timeout or connection limits on long-running uploads.
• Use network tools to capture network traffic during the upload. Look for stalled connections, retransmissions, or signs that a gateway is dropping or throttling the connection.

Tune Server and TCP Parameters

• Monitor server resources (CPU, memory, disk I/O) during the upload. A saturated server can fail to process incoming data fast enough, triggering TCP Zero Window conditions.
• Consider adjusting TCP buffer sizes on both client and server sides. In some environments, increasing the receive window size can delay or prevent the window from closing prematurely.

Try Alternate Network Paths

• If feasible, test the same upload on a different network or subnet. This can help determine whether the issue is specific to the current network segment, gateway, or firewall configuration.

In summary, it looks like the issue is not with RadAsyncUpload itself, but rather with how the network or storage layer handles prolonged, high-volume uploads. Narrowing down whether it is the file share, network devices, or system-level buffers will help resolve it.

Regards,
Rumen
Progress Telerik

[Richard]

Hi Rumen,

We have carried out exhaustive testing now and it is clear now that there is a Snort IPS rule on one of the gateways that is causing the upload to fail.

It seems that during the transfer there is a particular chunk that is being blocked by the rule:

https://www.snort.org/rule_docs/1-58741

The files that are failing to upload are SQL Server backups - each one fails at a different point, but with the same event type.

I assume there's nothing specific to the RadAsyncUpload itself that could cause a Log4j remote code execution attempt?  If there were then the first chunk would be blocked, and not, in this case, the 45th?

Does it seem more likely that there is some data stored in the backup that could be misinterpreted?  Snort have reported no known false positives for the rule in question.

Kind regards,

Richard