I hate to resurrect an old posting, but I too am having this issue. And it is seems only to be surrounded by things that use the SSH protocol. If I try to scp a large file (multiple Gigabytes), I will eventually the MAC incorrect error. If I use a non-SSH based protocol, everything works beautifully. For instance: rsync -hrlpt --progress filename.tar.zst rsync://x.x.x.x/transfer
This will transfer the whole file because I’m using the native rsync protocol. But if I use scp eventually I will get the MAC error and it will shutdown. I even used nc to transfer the same file without issues. It just seems like SSH doesn’t like something about receiving large files. I did discover that if I rate limit scp to about 48Mbit/s, I can transfer very large files with ease. But that’s not fun with 60+ GB files being transferred.
I even tried updating the kernel driver for the r8125 (there is a minor one on Realtek site) and that did not help. Could this be an issue with how the Rock chip is handling sustained, intense data transfers? Is the 5B+ doing any TCP offloading (I’ve seen this happen before with offloading)? Any boot params that might help with this?
That did the trick! scp transfers are solid and speedy. Thank you for the suggestion! We’re running Debian 12 on our 5b+, so I’ll share how I did the changeout of the kernel mods for the community:
sudo apt purge r8125-dkms
# This will remove radxa-system-config-r8125-dkms and r8125-dkms
sudo apt install r8168-dkms
# This includes the r8169 kernel module
sudo systemctl reboot
In fact, our new kernel comes with the r8169 module, just use rsetup to upgrade the system and run apt autopurge (don’t use remove, it will leave the r8125 configuration file behind).