clients loosing ipv6 internet now and then

Started by dMopp, August 17, 2024, 08:40:47 AM

Previous topic - Next topic

Well uh, I was able to observe similar looking behaviour.



root@opns:~ # tcpdump -n -nn -i vlan0.18 'icmp6 and not ip6[40] == 128 and not ip6[40] == 129'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vlan0.18, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:53:32.931734 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:34.002399 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:35.042986 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:38.957928 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:40.002543 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:41.052590 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:42.259048 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:43.282588 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:44.322688 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:46.333740 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:47.362818 IP6 fe80::1afd:74ff:fec1:2acd > ff02::1:ff65:3a25: ICMP6, neighbor solicitation, who has 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32
20:53:47.362850 IP6 fe80::xxxx:yyyy:zzzz:3a25 > fe80::1afd:74ff:fec1:2acd: ICMP6, neighbor advertisement, tgt is 2a0b:5c81:10:0:xxxx:yyyy:zzzz:3a25, length 32


BR, -sjm

Is this due to the pf FreeBSD SA ICMP issue too?

You can review the 24.7.2 kernel:

# opnsense-update -kr 24.7.2

(requires a reboot(


Cheers,
Franco

Just installed & rebooted. Looks good so far.

Ok, 24.7.2 is due tomorrow. Let's wait and see in this case :)

I will test my issue as well. Maybe related, maybe not. Will report then :)

@Franco : Cried victory too fast. Still the same erratic behaviour. I've turned off IPv6 for now.





Maybe another upstream oddity. I can put it on a list of things to dig through -.-


I am not using OPNsense Quality graph because I see similar behavior on my connection for a long time now(dpinger). I test my connection with smokeping. Maybe you can use that also for testing IPv6?

Quote from: cloudz on August 21, 2024, 07:28:41 AM
@Franco : Cried victory too fast. Still the same erratic behaviour. I've turned off IPv6 for now.





I see you're using Telenet. I see similar behavior on Telenet, but not on Proximus. Telenet also seemingly issues with Youtube etc (see the news..) - Could be the provider. I'll test "opnsense-update -kr 24.7.2" as well.

But it's not happening on 24.7 and before. I do see very high pings towards Google -- so that's a routing issue. These pings are to the modem/ipv6 bridge itself.

It could still be repercussions of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 introduced in 24.7.1 but I have absolutely no idea what the plan there is after the SA breaking it and then adding a few small patches on top that seem to fix the most apparent issues (included in 24.7.2), but perhaps not all of them.


Cheers,
Franco

Just to be sure have you tried reverting to 24.7 kernel instead?


Cheers,
Franco

Yes -- I went to the 24.7 kernel and that caused the drops to disappear but sometimes high spikes in CPU / interrupts which caused issues on IPv4 instead. But I did it with opnsense-revert & the update to the old kernel so might have caused some inconsistencies there.