Messages

Looks like the fix was already made but it's only scheduled for 25.7.8 now:

# opnsense-patch https://github.com/opnsense/core/commit/1a3744fc606


Cheers,
Franco

Are you using LAN tracking WAN via DHCPv6? Maybe there is an instability in your uplink.

I wouldn't suspect core changes at a first glance either, but maybe a newer Kea version could also be the culprit?

community/25.7/25.7.4:o ports: kea 3.0.1
community/25.7/25.7.7:o ports: kea 3.0.2

You can try the older Kea version from the 25.7 release:

# opnsense-revert -r 25.7.3 kea

or

# opnsense-revert -r 25.7.4 kea

or the latest

# opnsense-revert -r 25.7.7 kea



Cheers,
Franco

Well slower than not breaking it but the grid loading improvement in 25.7.7 was necessary and nicely speeds up all pages. Some pages differ in behaviour and cause these side effects during page loading.


Cheers,
Franco

It's almost like the client end of dynamic prefixes are not a business driver for Kea.  ;)


Cheers,
Franco

@OzziGoblin

gladly :)

@Maurice

I completely agree. The wizard will change scope a bit in 26.1 adding the concept of "use cases" which could eventually make Dnsmasq or Kea selectable in another major iteration. For now Dnsmasq in the wizard is tailored for the bulk users with simple setups.

You know where to find me. ;)


Cheers,
Franco

> How realistic is it that Kea can fully replace ISC by the time it becomes a plugin?

Good question. Honest answer:

Quite unrealistic due to a number of other priorities for 26.1. We're trying to adequately replace stock ISC DHCPv6 with Dnsmasq DHCPv6, but that will undo the ability to do PD delegation in new/wizard setups since that feature is not supported by Dnsmasq.

26.7 is more realistic, but that's easy to say now. Simply trying not to change all of the world at once and we can still rely on DHCP ISC for the time being. Extra help could change that, but it also needs a good plan and coordination to pull this off properly.


Cheers,
Franco

# opnsense-patch https://github.com/opnsense/core/commit/d9d3a548414


Cheers,
Franco

Similar issue on the packet capture page found already. We'll look into this one. Thanks for reporting it.


Cheers,
Franco

> Software problems are rhetoric? This is a novel concept.

In general it's always people that choose to make problems where there are none.  ;)

Hey :)

> Could you please tell me what the plan is for DHCP ISC? 

Sure.

> I know it will be retired and become a plugin, but when will this happen? 

26.1 will make ISC DHCP a plugin. As customary, if ISC DHCP is enabled the plugin will be auto-installed on the major upgrade so that the upgrade is seamless.

I don't know when the plugin will be sunset -- definitely not in 2026. Availability in FreeBSD ports is subject to fluid policies over there so I cannot make an predictions.

Plugins usually continue past their removal point as long as they are installed, but code may slowly break as it depends on functions that are going to be removed or rewritten in core beyond that point.

The software package itself will continue to work as long as FreeBSD doesn't introduce breaking changes in later releases, too.

TLDR; safe to assume 26.x will have the ISC DHCP plugin. Beyond that point is very difficult to assess today.

> Will we need to change any configurations to keep it running or will it continue as already implmented?

No.

Hope that helps.


Cheers,
Franco

> "Use IPv4 connectivity" has always been kind of misleading. This just meant that IPv6 uses the PPP interface, too, not the parent interface. That's the default now, so no need to look for this setting.

Code wise the bad thing about that setting has always been that enabling it is the implicit standard of the code, but the setting was designed as opt-in making the default non-standard and bloating the interface code with it.

On top of that the old disabled default can easily be achieved by assigning the parent interface and setting it to DHCPv6.

So as of 25.1 you have both the correct default for 99% of the use cases and still have the possibility to use the old-style setup if you need to. Though I'm not sure anybody actually needed that judging by the lack of feedback on this particular point.


Cheers,
Franco

> If I start with disconnected WAN interface it boots right through within 20 seconds.

I'd suspect there's some issue with the WAN link then to the ISP. I doubt packages are not sent out so they either get mangled or lost, or their response. Doing dhclient from the command line should yield the same behaviour and in that case a packet capture could tell us if packets are actually returned or not.

Still I doubt this an issue with the OPNsense per se.


Cheers,
Franco

@Jyling

You're approaching a point of no return in your rhetoric. I'm saying this because this is not the first thread I've seen where things appear to go into a wrong direction. Feel free to keep posting, but at some point I'll have to start actively moderating the situation.


Cheers,
Franco

Yep, thanks a lot for the report! :)


Cheers,
Franco

For everyone else. Works on my end as well:

# opnsense-patch https://github.com/opnsense/core/commit/30987d973ad

> but the real question is, nobody else is suffering this ?

I think most don't subscribe to system mail and or do not forward it.

The regression is relatively recent though since we used to use expiretable for that purpose, not pfctl:

> community/25.7/25.7:o firewall: removed the expiretable binary use in favour of the builtin pfctl


Cheers,
Franco