Ipv6 breaking on ath10k 5ghz wifi / multicast issue?

Software SW bugs discussion
1

I’ve noticed a problem with ipv6 on the 5ghz wifi (ath10k card). Forgive the long post.

Background: for ipv6 my ISP only supports SLAAC, not DHCPv6. so devices on my lan depend on getting router acknowledgements for the ipv6 prefix to use. Since RAs are sent out multicast, multicast needs to work consistently.

When the router first comes up, everything is fine and ipv6 to the devices on 5ghz wifi works. After a day or two, ipv6 stops working on the devices on 5ghz. tcpdump on the Omnia shows that when a 5ghz device connects to wifi, RAs are coming from the ISP, but simultaneous tcpdumps on the 5ghz devices show that they never get these RAs. Going to the 5ghz devices and disconnecting/reconnecting them from the network, and even rebooting these devices, did not get them back on ipv6, they still never got RAs.

I suspected perhaps the wifi interface on the Omnia was at issue, so I simply did

/sbin/wifi

on the Omnia to force a restart of the wifi interfaces, and magically, all of my 5ghz devices got ipv6 back. Note that even rebooting the 5ghz LAN devices did not help so I strongly suspect a problem with the ath10k/its drivers.

Can the Turris devs give a hint how to debug further? (I can provide the tcpdumps, but something way more low level is going on) If this is reproducible it will definitely break other important applications for multicast (eg DLNA streaming)

2

What about other interfaces? As far as I know, IPv6 relaying support is somehow broken in OpenWRT upstream, so I think it’s a general issue not related to the Wi-Fi at all.

You can, however, try to disable MLD snooping in the br-lan brigde, which sometimes causes some issues:

config interface 'lan'
        option igmp_snooping '0'
        …
3

I haven’t seen this issue on wired interfaces, or the 2.4ghz interface (although admittedly I have few devices on 2.4ghz). I’ve already turned igmp_snooping off as I had heard about that issue. ipv6 relaying definitely isn’t working for me, instead I"m using ebtables to bridge ipv6 traffic as described here. This is working well except for this issue. In prior Turris OS builds ebtables didn’t work at all (seg fault) but one of your developers fixed that recently, I believe by pulling in fixes from upstream.

4

I used to have an issue with IPv6 breaking over time in one environment. In that case it was because multicast didn’t work properly (hardware&driver issue in a router) and that broke IPv6 neighbor discovery. I noticed the issue by comparing what “ip neigh show” command shows when IPv6 works and when it is not working. In my case the workaround was to enable promiscuous mode for the interface in the router (ifconfig, ip link set)

5

white: for the Turris, something like

ip -6 neigh show

in the working and not working states, and if things look wonky then

ip link set eth0 promisc on
6

It was not from upstream but from a third party Alpine Linux distribution.

7

Yes, like that. In my case I had to enable the promisc mode for WAN interface. In your case you can try different interfaces.

8

Thanks. I definitely see the RAs making it from the WAN to the Turris, so in my case it might be LAN side.

9

@white setting promiscuous mode didn’t help. ipv6 RAs are still dropped after a day or two of router uptime and only on 5ghz. It still works properly on the Turris 2.4ghz, as well as a separate 2.4ghz access point I have connected to the to Turris. It really seems to be tied to the ath10k.

Any clues on how to debug this?

10

Still reproduces for me. None of the above tips worked, only thing that keeps IPv6 going as I mentioned is restarting wifi on the Turris regularly via cron. Any other ideas?