Messages

Thanks, that will help. Regarding the unbound snapshot... are you using amd64/OpenSSL or a different combination? I need to know to build the correct package.

What you are referring to is an update of the php-pfSense package, which is a module we've been wanting to get rid of ever since 15.1. The recent update 0.3 included only the removal of three functions, there was no code imported whatsoever. An upcoming iteration will remove this module for good.

(1) Yes, the version of unbound changed from 1.5.5 to 1.5.7. Unbound 1.5.8 is out for FreeBSD ports since today. If you are willing to try this as a preview to see if your issues go away I'm all for providing you with the snapshot and the necessary steps to update as well as options to revert to an older unbound version if you so desire to see if your experienced DNS instability was caused by unbound or not.

(2) Ok, thanks, I was being overly cautions of these changes, but what you describe could just be exclusive to (1).

(3) What is your network setup? Does this effect your WAN link only or all network transitions through the box?

Today is firmware upgrade day, I will have more time on Friday to give a response here.

I would wish that "serious problem" is not going to be a synonym for yet uncategorised behaviour that could range from virtualisation layer issues, bugs in OPNsense or things that predate the fork, solar flares, or something else entirely.

For me this is not a business and all free time, I have a day job and the courtesy of debugging complex setups is given out of care and respect for the project and the people behind it.

Hi there,

There are a couple of things we need to untangle here for clarity.

(1) DNS resolver has been reworked, especially for proper DHCP lease registration behaviour. Unbound 1.5.7 also broke briefly to to an inevitable upstream bug that was fixed in FreeBSD really just today with 1.5.8.

(2) Service start stop was reworked to offer plugins abilities to register services easily in the GUI. If there are bugs, we'll need to find a way to describe / reproduce them.

(3) Configd can crash, but leaves the system in a functional state so far as there is no GUI activity requiring system reconfiguration. Lockups of networking may trace back to IPS on Realtek hardware or other things out of our control.

(4) Without knowing which exact version changed things for you WRT to the above is not going to help as much as you will expect. We do provide fixes for a majority of users. The system is too complex to catch all use cases all the time. Unless these specifics are know, the chances of uncovering issues is not increasing, it's decreasing.

So any further help here is appreciated. :)


Cheers,
Franco

Tikimotel, we are removing more oddities from our code with 16.1.7 today, although we do target 16.1.8 for more fixes and also want to issue new images by then. Please let us know if 16.1.7 works better. :)

Hi there,

I will have to say some more about this. The ABI breakage of pkg happened silently and did not affect 16.1 to 16.1.5. It was triggered by the recent DHCP 4.2 -> 4.3 major bump and it seems to do something differently there. Suffice to say it will be back to normal again after today's 16.1.7.

Your update method also works, although it misses the base/kernel like you noticed. We have a tool called opnsense-update for this. :)

Changing the package URL in origin.conf can also be done like so:

# opnsense-update -sn "15.7\/latest"

(it needs an escaped forward slash for sed replacement, but then it works)

Upgrading the kernel/base is done by simply invoking:

# opnsense-update && /usr/local/etc/rc.reboot

Please do not defer the reboot using the internal script, it is essential.

The firmware upgrade or the console option (12) will do all of this portably, and there's also a command for scripting now that does it without all the questions, e.g. for a cron job.

# /usr/local/etc/rc.firmware


Cheers,
Franco

It could also be DNS simply not being properly configured on the box itself.

But in your case, upon rereading, it sounds like the installation is corrupted and the FreeBSD package tool refuses operation. What are your VM parameters in terms of disk space and RAM?

Did you try the cd installer config import->exit -> live cd feature to see if that brings up firmware updates?

There is no paid version, it has likely to do with the file you are trying to import.

Do you mind sharing the URL with us so we can take a look?

This will work again in 16.1.7 with a modified version of pkg that retains the 10.1 ABI compatibility. :)

Yay, cool. :)

16.1 did not have configd in the Services Diagnostics. You can, however, drop to the console and issue:

# service configd restart

What kind of hardware is this? The segfault may hint to smaller/older embedded hardware?


Cheers,
Franco

What's the purpose of OPT1 in this scenario? It might cause your routing table to get stuck having two subnets on two different ethernet ports. Without the use case you're after it's hard to say what to change.

I will try to push this in, but will have to change pkg to switch back to the old ABI in time for 16.1.7 so that the upgrade path works again. Thanks for reporting this.

Hi Manuel,

This is FreeBSD ABI breakage at its best from 10.1 to 10.2, geez...

Can you try the following for me?

Edit these lines in /usr/local/sbin/opnsense-update

https://github.com/opnsense/update/blob/master/update/opnsense-update.sh#L143-L146

"pkg" to "pkg-static"

And try again from the GUI


Cheers,
Franco

There will also be an upgrade target, that should be as far as we could possibly go ;)

# make upgrade