Upgrade to RC1 successful

[OPNenthu]

Maybe "Allow manual adjustment of DHCPv6 and Router Advertisements" was used on those LANs (also a bit earlier in time) which has led to several code problems over the years.

Indeed, it was used in the past.  I maybe even had it checked with Dnsmasq acting as the RA daemon, but the radvd service on all the interfaces was disabled.  I wasn't aware that after migration from ISC->Dnsmasq that I needed to also uncheck this option.

Still unclear why only those two interfaces in the screenshot showed up in the radvd service and were enabled, when I had several other interfaces configured identically.

I took a snapshot prior to the upgrades so I can roll back and try to reproduce... if that's helpful?  I could also save a copy of my config from that version.

Did you remove it from the GUI or via command line?

I uninstalled it from the GUI.

[Patrick M. Hausen]

Maybe "Allow manual adjustment of DHCPv6 and Router Advertisements" was used on those LANs (also a bit earlier in time) which has led to several code problems over the years.

If you have the time in the middle of a major release progressing, could you elaborate on that? This is my default setup literally everywhere.

TIA
Patrick

[franco]

I haven't seen the migration config diff so I can't say anything definite about it yet.

The migration has to assume all radvd servers found in the config.xml are in use when not disabled. The code for track6 and manual override option on top of radvd burried in ISC-DHCPv6 server settings is not easy to follow and may even have been wrong historically in some spots. So if you set a radvd entry for an interface at some point but it was disabled for interface settings specific reasons it may come back as enabled even if the code was previously treating it as not being started although set to enabled (not adhering to the specific configuration, but the overall interface IPv6 config). It's a complicated situation we're trying to untangle here.


Cheers,
Franco