IPv6 routing doesn't work with LRO and GRO switched off (or on)

[andrejpodzimek]

I'm using an AQC107 device on an ASRock x570 Creator with kernel 5.9.11 and ArchLinux. Based on this howto I thought that disabling LRO and GRO would make routing possible. Unfortunately, IPv6 routing doesn't work at all; for traffic both from and to the atlantic-driven interface. (Well, actually, when I left ping running for an entire day, ~10 packets made it through somehow. That's not many, out of ~86400.)

IPv4 routing works, however, even with LRO and GRO on.

IPv6 across one hop works fine as well, tested with both 10 Gb/s and 1 Gb/s links.

The same machine has other ethernet cards (USB and PCIe) and runs a hostapd WiFi AP. IPv6 routing works flawlessly for all those other interfaces, with pretty much the same configuration. The only difference from the other interfaces (in the .link file for systemd-networkd) would be:

GenericReceiveOffload=false
LargeReceiveOffload=false

But as already mentioned, this^^^ makes no difference in terms of IPv6 routing, which just doesn't work. (Of course I tried to set it directly with ethtool to double-check.)

Module versions I've tried:

• the default one in the mainline kernel
• 2.4.7 from this package
• 2.4.10 (by just tweaking the package)

I would have never thought that this could be a driver-related issue, but considering the fact that all the other interfaces route IPv6 just fine with the same configuration, an issue with this driver appears to be quite plausible.

From a tcpdump standpoint, packets heading out do appear on the incoming atlantic LAN interface, but then they don't appear on the WAN interface at all. Yet ip route get shows reasonable values and routing works fine from/to all other LAN interfaces. (Of course I've tried to disable nftables and all possible culprits a gazillion times.)

[andrejpodzimek]

I've just tried to use the atlantic card as a WAN interface instead of LAN, to make sure this is not just an issue with the network card on the other side. Well, nope, it was unable to forward anything over IPv6 to/from the provider (while IPv4 did work). A simple USB ethernet adapter in exactly the same spot of the "infrastructure" works fine, including IPv6 forwarding.

I'm still puzzled by the fact that a NIC driver is somehow IP(v6)-aware etc. As a client device (i.e., without any forwarding), this card works great at 10 Gb/s (with an Intel counterpart in my case). Once forwarding is on, IPv6 goes away.

[cail]

Andrej, that could be a packet construction problem, recently discovered in the driver.
It was fixed in upstream:
http://patchwork.ozlabs.org/project/netdev/patch/MWHPR1001MB23184F3EAFA413E0D1910EC9E8FC0@MWHPR1001MB2318.namprd10.prod.outlook.com/

You may try applying similar patch to the out of box driver from this github repo, or try patching in-kernel driver.

[andrejpodzimek]

It was fixed in upstream:
http://patchwork.ozlabs.org/project/netdev/patch/MWHPR1001MB23184F3EAFA413E0D1910EC9E8FC0@MWHPR1001MB2318.namprd10.prod.outlook.com/

You may try applying similar patch to the out of box driver from this github repo, or try patching in-kernel driver.

I can confirm that IPv6 routing works for me with this patch. 👍 I haven't made any changes to the GRO and LRO settings, so it works just fine with whatever the defaults are.

(I could only test it with a 1 Gb/s counterpart though, because I've decommissioned that machine's 10 Gb/s friend in the meantime.)

I've commented on the AUR package on how to build the patched module.

[cail]

Thank you for the confirmation!