tx offloading breaks ipv6

[mlipscombe]

IPv6 connections are unreliable when tx offloading is enabled. The symptoms are like there is an MTU issue between the two endpoints (for example, spamming dmesg stalls halfway through output), but the two endpoints are directly connected to an unmanaged switch and both have an MTU of 1500.

Running ethtool --offload eth0 tx off immediately resolves the problem.

This behaviour is the same on both linux-image-4.18.0-rc8-1060-ayufan-g45828c4db727 and and linux-image-4.4.132-1075-rockchip-ayufan-ga83beded8524.

[carlosedp]

Not sure if you are using the RockPro64 board but if it's the case, the file that disables offloading needs update to have the device ID of the RK3399 boards.

Need to edit /etc/network/if-up.d/rock64-offload, adding the RK3399 ID:

#!/bin/sh

ETHTOOL=/sbin/ethtool

test -x $ETHTOOL || exit 0

[ -d "/sys/devices/platform/fe300000.ethernet/net/$IFACE" ] || [ -d "/sys/devices/platform/ff540000.eth/net/$IFACE" ] || [ -d "/sys/devices/platform/ff540000.ethernet/net/$IFACE" ] || exit 0

$ETHTOOL -K "$IFACE" rx off tx off

@ayufan Can you update the script to add this? I've checked and three RK3399 boards I have (Firefly, FriendlyARM and RockPro64 have the same "fe300000" ID).

[bingmann]

This also fixes obscure IPv4 network problems on my setup when transfering lots of data via http.

[TCB13]

@bingmann this might have fixed the issue with HTTP, however I'm still having issues with HTTPS - no ideia why it only happens with SSL. The transfer just stops after a while. Other protocols and plain text HTTP work fine for me. I've made a post about this here https://unix.stackexchange.com/questions/494290/apache2-ssl-large-download-hangs.

Continuing discussion here: https://github.com/Fourdee/DietPi/issues/2028.

PS: My device is a NanoPi M4 but since the CPU is the same, probably same kind of issues.