Thanks for sharing your findings!

Tell you a good news, this problem has been solved.
It is because the author of XMiR-Patcher (Firmware patcher for Xiaomi routers) compiled the binaries for MIPS incorrectly, and they have fixed this bug now.
I'm also very grateful for your patience in listening to my report, although it turns out it was completely not your fault in the end. Wishing your product gets even better~(°∀°)ﾉ

https://github.com/openwrt-xiaomi/xmir-patcher/issues/139

PS: When this issue occurred before, I found that transferring data directly using scp -O and MobaXterm both worked normally, so it was only WinSCP that was causing the problem. So, subconsciously, I thought it was an issue with WinSCP, haha~ฅ՞•ﻌ•՞ฅ

Wow, so this software was completely made and maintained by you alone? (⊙ｏ⊙)
Thanks for your hard work. I hope the logs I provided can help you find the issue and fix it soon, haha~|ω・）

Thanks for more details. Though there's no "engineering team". It's just me.

I have also captured logs in Debug 1 and Debug 2 modes, which I have attached below for both sessions. Please pass these on to your engineering team for further investigation. I really enjoy using WinSCP and hope this issue can be identified and resolved soon.

Also, I should mention that the Xiaomi router OS is a highly customized version based on OpenWrt. I'm providing the firmware download link for my specific router model below, as it might be helpful for your technical analysis:

Firmware Link (Xiaomi BE6500):
https://cdn.cnbj1.fds.api.mi-img.com/xiaoqiang/rom/rn02/miwifi_rn02_firmware_f7df7_1.0.43.bin

Thanks for your detailed report.
Unfortunately, I do not know what else to try. Everything I would have suggested, you have tried already.

Dear WinSCP Team,

I am writing to report a persistent connection issue I am encountering when using WinSCP to upload files to my Xiaomi Router BE6500 (which runs a customized OpenWrt/BusyBox system with Dropbear SSH).

The Issue:
When uploading files using the SCP protocol, I consistently receive the error:

Network error: Software caused connection abort

Behavior Details:
Login and directory listing work perfectly.
The error occurs specifically during the file data transfer phase.
I can confirm that the transfer starts, and a file (with 0 or partial size) is created on the server side before the connection drops.

The Anomaly:
The behavior is highly dependent on the target directory, which is very strange:
Uploading to /data/userdisk -> Success.
Uploading to /data/userdisk/data -> Fails with the error above.
(Note: Both directories appear to have identical permissions rwxr-xr-x).

Troubleshooting Attempts:
I have tried enabling almost all compatibility options to mimic a "dumb" SCP client, but none of the following settings resolved the issue:

• Unchecked "Optimize connection buffer size"
  
• Unchecked "Lookup user groups"
  
• Disabled "Enable transfer resume/transfer to temporary filename"
  
• Unchecked "Preserve timestamp"
  
• Unchecked "Set permissions"
  
• Unchecked "Encrypt new files"
  
• Unchecked "Calculate total size"
  
• Set Shell to /bin/sh
  

Comparison (Control Group):
Crucially, the file transfer works perfectly to the exact same destination (/data/userdisk/data) when using:
Windows built-in OpenSSH client: scp -O source target works fine.
MobaXterm: Works fine.

Environment:
Local OS: Windows 10 Enterprise 22H2 (Build 19045)
WinSCP Version: 6.5.5 (Build 16453). Note: The issue persists in version 6.5.5 and multiple older versions.
Remote Device: Xiaomi Router BE6500 (XiaoQiang)
Transfer Protocol: SCP

It appears that WinSCP's implementation conflicts with the router's SCP server in this specific scenario, even with all "smart" features disabled.

Attached are the session logs for your reference.
Best regards