Everything is set to default settings. Freshly installed. Not a single option is included and it throws an error again. I think I'm giving up and going back to stock firmware until this is resolved. Thanks everyone
What scp client do you use? Some clients are enforcing āOptimize connectionā features by default and that might mess with the transfer.
1 Like
Thanks for the answer, I use WinSpc via the command line and Optimize connection is turned off. But it's not a problem with the SCP client because I have same problems when I work with Rsnc via NAS. I will write again that I transfer data in the same way on OpenWRT as well as on stock firmware, with the fact that I only have a problem with OpenWRT.
Please also try to reproduce the issue by downloading large files via unencrypted HTTP from public servers (or, even better, from your own VPS in the cloud) and comparing MD5 sums. This has the advantage that you can run tcpdump on both sides and present irrefutable proof of data corruption that still passes TCP checksums (that's why I mentioned PPPoE earlier).
I was specifically referring to WinSCP, since it's known to have that issue (it's not WinSCP problem per se).
I had similar problems with rsync on some previous snapshots, but haven't noticed it for the past few weeks.
For me, the problem appears only with files that are large, say over 100GB. But anyway, the problem exists.
I had the same problem with SCP and 20GB+ file today. The file transfer breaks. Itās Linux between Linux.
Software Offload and SQM enabled. Looks like a bug to me.
1 Like
That's what I'm talking about... Hvala... Thanks for the confirmation
I'm no expert but isn't there some possible conflicts with software or hardware offloading when sqm is on? Maybe this is one.
1 Like
Offloading, hard- and software, would be the first thing I would disable for debugging this further.
1 Like
Maybe I wait a couple of weeks until this problem is solved before I make the switch to OpenWRT on my AX6000.
I also transfer large files on weekly basis, Using rsync, to a remote backup (linux to linux). I can't afford file corruption.
Today I tried again with a clean install. I even turned off Software Offload and SQM, but the problem is still there. I'm definitely going back to stock firmware until this issue is resolved.
Abit off topic but what do you think of the stock firmware of the TUF? Is it responsive?
The problem is that the issue is not consistent. It never happens on the same files or at the same time, at least not for me. Repeating the sync often times resolves the issue, so Iām personally not very concerned by the issue.
- Is your PC connected to 1GbE or 2.5GbE port? If 2.5GbE, can you try using 1GbE port?
- Does this thing happen on LAN or WAN connections (or both)?
- Did you use trx or serial port method to install OpenWrt initramfs?
This issue most likely has something to do with our specific configuration, since I donāt see anybody else reporting it, including guys in TUF-AX4200 thread.
Letās wait what @patrykk has to say. We are trying to reproduce the problem on his end.
For everybody else - I would not be worried too much about this issue, since Iām sure it is related to our specific configuration. Feel free to enjoy this hardware on OpenWrt in its full glory. 
SQM only works with software offloading.
To be honest, I donāt think itās related to SQM or offloading.
I still would not be assuming anything, since so far itās an issolated incident (only @whitedd and me). It is probably only related to our specific configuration.
I would like to confirm the symptoms. And, given that @whitedd has already reverted to stock, I have to ask you.
The symptoms to be confirmed are that the corrupted packet has its TCP checksum correct. Or rather that there are other corrupted packets, with the wrong TCP checksum, that happen 65535x more frequently.
For that, please perform a network capture at both ends: tcpdump -pni eth0 -w file.pcap. Yes, I know, it would be two more 100 GB files, but you can then use tools like editcap to get only the beginning and the end, resulting in much more manageable 1 GB files that can be posted for diagnostics.
1 Like
Hi,
I had no any specific configuration.
1.Clean install
2.Problem is with 1GbE and 2.5GbE port
3. Using WAN connection
4. Installed using trx
Are you using any Per Packet Overhead in SQM Link Layer Adaptation? I use "none" for Link layer, but there probably should have been used something.
In last test before i return to stock i didn't use SQM at all.
Looks like somebody had similar issues in past.
Is it possible that this is an ISP related problem, caused by the default settings in Firewall - Zone Settings (MSS Clamping)? Sounds like an MTU specific problem.
I'm not very familiar with the topic, but could give an idea to guys who are more familiar with it. I would be glad to do the testing.