Messages

I've asked IPinfo to take a look. Also make sure the maximum table entries value is not too small.


Cheers,
Franco

The patch doesn't really fix anything, just do "rm /var/etc/radvd.conf" if you think you have the problem but I doubt it given the data you have provided.


Cheers,
Franco

Well, we're talking about the documented cron job name "periodic interface reset":

https://docs.opnsense.org/manual/settingsmenu.html#cron

And not all interfaces use DHCP but can still be "periodically reset".

Please don't shoot the messenger.  This terminology was invented before we started our project.  :)


Cheers,
Franco

Not sure that is a good idea. We try to avoid disk manipulation if not strictly necessary. We've also never messed with /etc/fstab for that reason. Except for missing bootloader updates (which also FreeBSD is working towards) I think this is a good policy.


Cheers,
Franco

Well it cannot renew, but the interface reset is indeed what you want it will release and get a new one.


Cheers,
Franco

Wow! 🤯

Hehe!  It's been used for the Nano images in particular on first boot for a long time, but it's indeed reusable and works for VMs just as well.


Cheers,
Franco

https://github.com/opnsense/core/commit/5da971f2c67 should help here.  It currently does not apply to 25.7.x as a lot of changes are inbound for 26.1 already.


Cheers,
Franco

Ok, right, radvd is for LAN connections. Running it on a WAN has the risk of DHCPv6 client picking up its own configuration and that's why the sanity check was put in place.

https://github.com/opnsense/core/commit/572ae8a66575

Although that was done for SLAAC tracking which no longer exists the same is true for DHCPv6.

We can try to make sure that radvd.conf is cleared and the log message is easier to find from the GUI.


Cheers,
Franco

Ok, I hadn't thought of that.  That will make testing via VM client easy.  :)

I mostly test against the Fritzbox these days.  Still pondering how to build an effective test suite around dhcp6c in the codebase itself to emulate such things, perhaps with packet captures.


Thanks,
Franco

FWIW, here is a similar report.

https://github.com/opnsense/core/issues/9153

If we can find the bug where ever it is that would be great.


Cheers,
Franco

I suppose you are right.  I can only give my outside perspective here.  There's definitely a structural issue at play here that makes inclusion and mutual respect wishes on a paper more than anything that is lived by.  I believe we can all agree on a technical patch that goes throw a review process.  FreeBSD has all the tools and interested people to do it.  The unspoken exercised culture, however, is one of lack of accountability and likely hard to overcome to be more goal oriented, open and collaborative.  Things that nobody else cares about are not tended to even if contributions exist.  This is where FreeBSD loses traction that would be an easy win.

Now at least some of my ports found no delay in maintainership which I find good and strange at the same time as if this behaviour fixes a structural problem the ports were having.  I hope that incentive lasts, yet ports already start falling behind with CVEs and upstream releases out in the wild.  Very happy that's not the case for our users, because there is an established process: test -> commit -> ship -> enjoy  :)


Cheers,
Franco

Just as a note if "fetch" doesn't work try "curl -o <filename> <url>" -- it means duplicating the file name on the command line for opnsense-update to find it but properly in the local directory (which is what "-l .") is about.


Cheers,
Franco

Great. Can you share the log line here or via PM? I don't have a setup obviously. Just for double-checking.


Thanks,
Franco

Here's an example for 25.7.11 base/kernel with signature verification (which requires 25.7.x to verify ok but is safer in your case):

# fetch https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/sets/kernel-25.7.11-amd64.txz
# fetch https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/sets/kernel-25.7.11-amd64.txz.sig
# fetch https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/sets/base-25.7.11-amd64.txz
# fetch https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/sets/base-25.7.11-amd64.txz.sig
# opnsense-update -bkr 25.7.11 -l .
# opnsense-shell reboot

If signatures still fail curl may be an option, too.


Cheers,
Franco

It seems all issues have now been recorded in https://github.com/opnsense/hostwatch/issues and don't need to be reposted.

Let's give it a bit of slack to be resolved.


Cheers,
Franco