Messages

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


Cheers,
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

It's queued up for a soon-to-be (but non-critical) hotfix in 25.7.11 (when we also add the upgrade path to 26.1).


Cheers,
Franco

ok, nice, thanks for the feedback :)

I'm still missing the point a bit: it was said it's broken because it's spamming. The question is: is it still working after upgrading from 25.7.11 (where it worked) to 26.1-RCx (in which the code really doesn't differ)?


Cheers,
Franco

@OPNenthu strange bugs but let's go through them:

- After upgrade, the radvd service was enabled on two interfaces where it was not previously enabled.  I'm using Dnsmasq for RAs on all interfaces.

- After I manually switched all my interfaces from "Track Interface (legacy)" to "Identity Association," radvd then disabled itself everywhere.

The config history in those cases (especially the migration of radvd) would be nice to know here. But what I can say here already is that track6 has automatic starts of interfaces as well so your second point is just a statement of how it works.  I'm just not sure which interfaces you refer to (the ones seen there or not). 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.

- Finally I uninstalled the 'os-isc-dhcp' plugin (I think it was labelled as 'development' even though I switched back to the Community branch after upgrade).  This caused the UI to break down and required a reboot.

First part is easy... packages including plugins are sticky and that was also explained better here (granted I modified it later because Maurice mentioned it):

https://forum.opnsense.org/index.php?topic=50472.msg257544#msg257544

Second part I'm unsure about. Browser console might have told us something. That it's back after reboot makes it stranger. As far as plugins are concerned nothing special happens.  Did you remove it from the GUI or via command line?


Cheers,
Franco

There is DUID and then MAC address right below it in reservations.


Cheers,
Franco

Wasn't it this one? https://github.com/opnsense/plugins/commit/2cc2215bb

If so we're hotfixing this for the last update of 25.7.11_x shortly after 26.1 is out this week.


Cheers,
Franco

It kind of depends what parameters you're targeting the traffic on. You can just use a floating rule without an interface selected while select the source or destination of the traffic in an "in" direction rule correctly. There's no apparent need for an interface and routing domains don't exist so networks don't overlap in a routing setup.


Cheers,
Franco

"state-policy" directives have nothing to do with the parting of the rule GUI "floating" tab concept and they won't change behaviour either.


Cheers,
Farnco

True, it's more likely the errors were always there or at least for a while.


Cheers,
Franco

> What I did see was two popups about errors and then this in the crash reporter:

That's the usual update hiccup.  I think that at some point we will consider replacing files instead of a flat delete and install that pkg is doing, but not yet.

> Did not see too many php-cgi processes, but I did not have rapid commit enabled.

The two are not related.  ;)

> Don't know about the hostwatch thing.

The missing automatic flag comes from using "pkg install" or "pkg add -f" on the command line. opnsense-revert can take care of it:

# opnsense-revert hostwatch


Cheers,
Franco

It will always auto-install when doing the upgrade 25.7 -> 26.1, yes.


Cheers,
Franco

First time I hear this. Kernel ABI and upstream software didn't change from 25.7.x so not sure what we're looking at here.



Cheers,
Franco

A hotfix release was issued as 26.1.r2_2:

o interfaces: if no idassoc6/track6 LAN is used also emit a PD request like before
o firewall: make previously associated DNAT rules editable