core
core copied to clipboard
opnsense
radvd not deprecating prefixes when pppoe connection is manually disconnected
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [ x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [ x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Describe the bug
I configured DSL over PPPoE as described in https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html if pppoe is disconnected manually via Interfaces -> Overview -> pppoe1 -> disconnect button then opnsense properly removes the global ipv6 addresses from its interfaces. The radvd config still contains the now deprecated prefix and no advertisment is sent to the clients. The only thing to get rid of the stale client prefixes is to either reestablish the pppoe connection or manually restarting radvd.
Expected behavior
When pppoe goes down, radvd shall announce deprecation without manual intervention
Add any other context about the problem here.
On the interfaces "Allow manual adjustment of DHCPv6 and Router Advertisements" is enabled and Router Advertisment is configured to "Unmanaged". I played with multiple settings and none of them seem to work.
Software version used and hardware type if relevant, e.g.:
OPNsense 23.7.8_1-amd64
That’s unlikely since radvd.conf should have the right setting… check /var/etc/radvd.conf first.
01_after_disconnect.radvd.conf.log 02_after_restart_radvd.radvd.conf.log
The first file shows the content after manually disconnecting the pppoe connection, which does not differ from that one before disconnecting, still containing the prefixes which should be deprecated.
The second one is the content after manually restarting radvd from webgui.
At first glance I don't see a bug: deprecate configuration is set and restarting will deprecated the prefix by design. I don't see why it doesn't, at least on the wire.... Have you confirmed?
The only thing I can imagine in this scenario is radvd not restarting when the prefix is actually deprecated missing an IPv6 renew trigger, but in these cases you can sort of confirm with the PID not having changed in radvd and dhcp6c having released the prefix. If, however, dhcp6c hasn't released the prefix but it has expired there is not much radvd can do in turn because it needs to know the renew failed.
Cheers, Franco
I haven't done any wireshark capture if you mean that, but I can confirm that multiple clients (Linux, Android) still assign an deprecated ipv6 if interface reconfiguration is forced, which doesn't happen after manually restarting radvd.
The pid of radvd doesn't change if I bring pppoe down. I also tried with the 'Prevent release' option enabled and disabled but it doesn't have any effect.
How can I find out if dhcp6c has released the prefix?
To be frank the disconnect button on the overview page is no longer there for various reasons when 24.1 is out at the end of this month. It wasn't really a full cycle shutdown which may or may not cause this. The bigger question perhaps is if this a problem in normal operation?
Well if the connection is lost due to external reasons (modem loses sync, DSLAM reconfigures/reboots etc), the prefixes don't get deprecated as well. Even worse in that case even radvd doesn't help.
So the whole multi-wan thing is not working properly when v6 is involved because most clients try to prefer v6 and with that dead end v6 address the experience is not so good. The only way to reliably get it working is having a v4 only setup, which in turn isn't such a good thing in 2024.
Well if the connection is lost due to external reasons (modem loses sync, DSLAM reconfigures/reboots etc), the prefixes don't get deprecated as well. Even worse in that case even radvd doesn't help.
I appreciate the enthusiasm, but this is not something we can easily fix since at least DHCPv6 misses a mechanism to revoke a prefix, let alone allowing a DSLAM power outage signal to a downstream router that its valid prefix was lost on the upstream router. If only static IPv6 addressing could fix that. ;)
The only way to reliably get it working is having a v4 only setup, which in turn isn't such a good thing in 2024.
I'm just not sure how we can pad everything from here to deal with problems that we can not even see. As long as the prefix is assigned and not released it is intended for use...
I understand that things might not be easy to fix. However if I pull out the cable and gateway monitoring marks the gateway as down and the underlying pppoe connection is also detected as disconnected my naive assumption was that the associated prefixes should then as well get deprecated.
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
