Partially lost IPv6 since upgrade from TOS 5.x to TOS 6.x

Hi,

I lost part of my IPv6 connectivity since the upgrade to TOS 6.0.1. I have no issue from the Turris Omnia itself or one computer but from another one, only local addresses are reachable, nothing on Internet side.

I have dualstack connectivity:

/etc/confignetwork`:

config interface 'wan'
        option proto 'dhcp'
        option vendorid 'neufbox_xxx'
        option device 'eth2'

config interface 'wan6'
        option proto 'dhcpv6'
        option device '@wan'

Configuration on client side is very basic (managed by systemd-networkd), identical on both clients (the working and not working one):

[Match]
Name=eth0

[Network]
DHCP=yes

[DHCP]
UseDomains=true

On both clients I get an IP6 from within the delegate range and one in fe80. IP6 routes are broadly the same.

Yet, on non working client, I cannot ping/curl/tracepath anything else than other client and turris router (edit: I cannot ping the turris router, only the other client).
If I do a tcpdump, I see the request but no response.

Everything work fine once I disable IPv6 on the non working client but this is only a temporary workaround.

When I do a ping from the non working host, I do see the ping reply on the turris:

17:58:55.826997 IP6 2a02:842a:xxxx:xxxx::42 > 2a00:1450:4007:809::200e: ICMP6, echo request, seq 18, length 64
17:58:55.834171 IP6 2a00:1450:4007:809::200e > 2a02:842a:xxxx:xxxx::42: ICMP6, echo reply, seq 18, length 64
17:58:56.837043 IP6 2a02:842a:xxxx:xxxx::42 > 2a00:1450:4007:809::200e: ICMP6, echo request, seq 19, length 64
17:58:56.843028 IP6 2a00:1450:4007:809::200e > 2a02:842a:xxxx:xxxx::42: ICMP6, echo reply, seq 19, length 64

but it never reaches the host:

PING ipv6.google.com(par10s27-in-x0e.1e100.net (2a00:1450:4007:809::200e)) 56 data bytes
^C
--- ipv6.google.com ping statistics ---
22 packets transmitted, 0 received, 100% packet loss, time 21288ms

which is confirmed as I cannot see the reply when doing the tcpdump on br-lan instead of eth2:

18:04:56.482530 IP6 2a02:842a:xxxx:xxxx::42 > 2a00:1450:4007:809::200e: ICMP6, echo request, seq 1, length 64
18:04:57.503507 IP6 2a02:842a:xxxx:xxxx::42 > 2a00:1450:4007:809::200e: ICMP6, echo request, seq 2, length 64

At router boot, I get following routes:

default from 2a02:842a:xxxx:xx00::/56 via fe80::5555 dev eth2 proto static metric 512 pref medium
2a02:842a:xxxx:xx00::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2a02:842a:xxxx:xx00::/56 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev eth2 proto kernel metric 256 pref medium
fe80::/64 dev vethCmXxSc proto kernel metric 256 pref medium

After generating traffic from the non working host, I see an extra route which is strange:

default from 2a02:842a:xxxx:xx00::/56 via fe80::5555 dev eth2 proto static metric 512 pref medium
2a02:842a:xxxx:xx00::/64 dev br-lan proto static metric 1024 pref medium
2a02:842a:xxxx:xx04::/62 via fe80::xxxx:xxxx:xxxx:66b0 dev br-lan proto static metric 1024 pref medium
unreachable 2a02:842a:xxxx:xx00::/56 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev eth2 proto kernel metric 256 pref medium
fe80::/64 dev vethCmXxSc proto kernel metric 256 pref medium
fe80::/64 dev ifb4eth2 proto kernel metric 256 pref medium

fe80::xxxx:xxxx:xxxx:66b0 belongs to the non working host.

Manually removing that route does not fix the issue.

Any feedback on this or should I contact support directly?

I have similar or the same problems.

At one location IPv6 was not working at all, but all hosts had their IPv6-addresses set. While comparing configurations with other routers, I noticed the WAN bridge was somehow missing in /etc/config/network. After adding it manually, IPv6 worked again. IPv4 did not seem to be affected by this.

But since yesterday I have the problem you describe at another location. Some hosts work (mostly desktops with network-manager) others don’t (mostly servers with systemd-networkd).

They can reach each other, but the ones who don’t work can’t reach the router.

Sometimes after changing settings on the router it works for a few minutes only, but then stops again without having changed anything.

The following OpenWrt topic looks very similar:

Yes, I saw that topic as well but it ended before any real finding was shared.

The behavior is very inconsistent.
Manually restarting the network (/etc/init.d/network restart) solves the problem for some time.
IPv6 services on my LAN will be reachable and working again for 5 minutes only or for several hours.
The services don’t fail all at the same time. Often used services, like DNS servers, tend to work for longer periods but eventually all will be unreachable.
Even while some services remain working from outside, pings from the Omnia to their LAN IPv6 addresses fail most of the time. Out of ~20 addresses maybe one or two will respond to ping from the Omnia. Odd is also, most of the time these IPv6 hosts can ping the router, but not vice-versa.

More out of a hunch, I disabled IGMP-Snooping on my Switches and the Omnia LAN-Bridge, since it IGMPProy is currently unusable anyway in TOS 6. And suddenly all IPv6 addresses are pingable again from the Omnia.

I will have to wait a few hours, to see if it services and pings will remain stable.

With IGPMP snooping disabled, my IPv6 is working without issues since more then 24 hours now.

I tested several times. IPV6 pings start to fail as soon as I re-enable IGMP snooping.

1 Like

Have you tried forcing IGMP version 3 in sysctl:

my defaults are:

net.ipv4.conf.all.force_igmp_version = 0
net.ipv4.conf.default.force_igmp_version = 0
net.ipv4.conf.eth0.force_igmp_version = 0
net.ipv4.conf.eth1.force_igmp_version = 0
net.ipv4.conf.lo.force_igmp_version = 0
net.ipv4.conf.virbr0.force_igmp_version = 0

but I am not using IGMP at all and I seem to have no issues on either macos monterey, Ubuntu 22 or android 11 clients.

I tried that and many other settings, but in Luci not with sysctl.

This particular device has been factory reset for the update to TOS 6.

Four other devices have been updated and migrated from TOS 5, of which two of them have VLANs and IGMP-Snooping enabled, but IGMP is restricted to particular VLANs. None of the others showed any issues with IPv6.

Its hard to say what is really going on. Its an IPv6 problem, but IGMP is IPv4 multicast.
So it looks like an L2 problem. Could also be the switch who is acting weird.

Thanks for your investigation @milkandhoney
I get as well a working setup when disabling IGMPSnooping.