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

[Patrick M. Hausen]

I never used DHCPv6. I manually enabled radvd everywhere I needed it. Time will tell :-)

[franco]

I think I'd have heard from you about that already.  :)


Cheers,
Franco

[OPNenthu]

@franco I've completed the rollback to 25.7.11_2 and taken a fresh snapshot, so am free to start the upgrade toward 26.1.r2_2 now.  I've already downloaded the config from 25.7.11_2.  What else might be needed from it?

BTW: this instance of 25.7.11_2 has some manual patches applied per our previous testing, e.g. hostwatch v1.0.6 and the dhcp6c improvement from the "CALL FOR TESTING" thread.

[franco]

Local patches and test packages are not an issue.  The upgrade will remove them.

Just make sure to directly follow up RC1 with RC2 and a reboot to ensure consistency within the latest RC2 code.

The final update to 26.1 will take care of this eventually, but intermediate RCs are a bit "floating" in terms of overall integration.  ;)


Cheers,
Franco

[OPNenthu]

(Sorry, saw your message too late.  I didn't reboot after RC2.)

---

Ok, I'm getting a different set of results this time, but still some issues.

This time I got a php error after the last upgrade toward 26.1.r2_2 and I submitted the crash report from within the GUI.

I saw that on the intermediate upgrade to 26.1.r_9, the list of interfaces under Services->Router Advertisements had already shrunk down to two interfaces from the full set of ten internal interfaces that I have, and it's the same two as before (LAN & CLEAR).  The other 8 interfaces are missing from the radvd list, even though they all have the same settings (Track Interface w/ Allow manual adjustments checked).  The difference this time is that the radvd service was not enabled on them after the upgrade.

Next I manually changed all the internal interfaces to "Identity Association," and as before I clicked "Save" between each interface change and applied them all in one shot at the end.  It took a bit to process and my WAN IPv6 gateway went down for some reason (I didn't edit that interface) but came up after some time.  The UI is still responding at this point.

Finally I removed the ISC plugin from the GUI.  This time I did not get a crash.  The GUI is still responding.

So clearly the upgrade is not deterministic even when starting from the "same" state.  This surprised me.

Anyhow, I have the before/intermediate/after configs and I also captured the terminal buffer during the major upgrade to 26.1.r_9.  Let me know if you need me to send them to you.