On 05.04.21 15:27, Andrew Lunn wrote:
On Mon, Apr 05, 2021 at 02:53:15PM +0200, Julian Labus wrote:
Hi all,
in our community mesh network we recently discovered that a TP-Link Archer
C2600 device is unable to receive IPv6 UDP packets with a zero checksum when
RX checksum offloading is enabled. The device uses ipq806x-gmac-dwmac for
its ethernet ports.
According to https://tools.ietf.org/html/rfc2460#section-8.1 this sounds
like correct behavior as it says a UDP checksum must not be zero for IPv6
packets. But this definition was relaxed in
https://tools.ietf.org/html/rfc6935#section-5 to allow zero checksums in
tunneling protocols like VXLAN where we discovered the problem.
Can the behavior of the stmmac driver be changed to meet RFC6935 or would it
be possible to make the (RX) Checksum Offloading Engine configurable via a
device tree property to disable it in environments were it causes problems?
Hi Julian
I don't know the stmmac driver at all...
Have you played around with ethtool -k/-K? Can use this to turn off
hardware checksums?
I doubt a DT property would be accepted. What you probably want to do
is react on the NETDEV notifiers for when an upper interface is
changed. If a VXLAN interface is added, turn off hardware checksums.
Andrew
Hi Andrew,
yes, disabling the offloading via "ethtool -K <ifname> rx off" works and
is used as a workaround in a startup script but the OpenWrt-based OS on
the mentioned device does not provide a reliable way to trigger ethtool
commands when network devices change.
Reacting to upper interface changes and disabling (rx) offloading per
interface sounds right when looking at RFC6935 again.
"As an alternative, certain protocols that use UDP as a tunnel
encapsulation MAY enable zero-checksum mode for a specific port
(or set of ports) for sending and/or receiving."
But was is still a bit strange to me is that it seems like the stmmac
driver behaves different than other ethernet drivers which do not drop
UDP packets with zero checksums when rx checksumming is enabled.
Julian
