Nanopi M4 and other RK3399 need TCP/UDP offloading disabled

[Jerry Jyrer]

Hi all,

 

I'd just like to share a problem I experienced and what solved after a bit of Googling. Basically, I have Nextcloud installed on my Nanopi M4 (v1) with Armbian:

$ uname -a

Linux nanopim4 4.4.192-rk3399

 

When I sync files from my Android phone via local wifi, often the transfers were just failed. Not always but usually, it's when a directory contains lot of large files. After a bit of Googling and came across this: https://unix.stackexchange.com/questions/494290/nanopi-m4-rk3399-apache2-ssl-large-download-hangs/495378#495378

 

It works. The problem's solved after:

 

ethtool -K eth0 rx off tx off

 

and put the command in /etc/network/if-up.d/ethtool

 

Just wondering if anyone knows the root cause and have better solution than disabling things. 

 

Thanks,

 

 

 

 

 

 

 

 

[Akeo]

Yes, TCP/UDP offloading MUST be disabled for NanoPi, NanoPC.

 

With offloading enabled, Samba becomes completely useless, as you will find that transfers to a Windows PC freeze randomly (usually on large files).

 

Disabling offloading should be the default for RK3399 Armbian builds, as I spent months thinking there existed a bug with Samba/ARM64 before finding this post.

 

For the record, this is what I added to my NanoPC Armbian installation as /etc/network/if-up.d/disable-rk3399-eth-offloading:

 

#!/bin/bash

[ "$IFACE" == "eth0" ] || exit 0
ETHTOOL=/sbin/ethtool
[ -f $ETHTOOL ] || exit 2

[ -d /sys/devices/platform/fe300000.ethernet/net/$IFACE ] || exit 6
$ETHTOOL -K eth0 rx off tx off

exit 0

 

[lanefu]

thanks for reporting. created issue https://armbian.atlassian.net/projects/AR/issues/AR-348

[Igor]

Since we use NetworkManager perhaps this way https://github.com/armbian/build/pull/2079  ?

[piter75]

26 minutes ago, Igor said:

Since we use NetworkManager perhaps this way https://github.com/armbian/build/pull/2079  ?

I think we should try to fix it for legacy in a similar manner as we did it for both current and dev. In dev the patch is gone as it is already upstreamed.

 

I did not try to fix it in legacy as I thought it was not a problem there ;-)

[piter75]

On a second thought though these properties may not be available in legacy

If so then going with the ethtool may indeed be the only option.

[Igor]

15 minutes ago, piter75 said:

I did not try to fix it in legacy as I thought it was not a problem there ;-)

I also don't tend to use / pay much attention to / legacy anymore ... So we add one more IF sentence to check kernel version so that it won't touch modern kernels ... since there, its not needed, right?

[piter75]

4 minutes ago, Igor said:

So we add one more IF sentence to check kernel version so that it won't touch modern kernels ... since there, its not needed, right?

I think I would go this route.

In modern kernel it's not needed in standard environments (MTU 1500).