Messages

I'm not sure what to make of your concerns here.

The primary concern of instability was resolved and was the result of a failed upgrade attempt due to unknown reasons.

The secondary concern is that the firmware is pretty old on my NIC and I was looking into updating it BUT rather than just update to the latest firmware and hope for the best, I was hoping either supported firmware versions were listed in the driver documentation some where -or- someone running the same card could confirm known good firmware/driver combinations.

Not having much luck getting that info, so for now the production build will remain as it is and I'll spin up a development one. I bought another of the same NIC card so I can update the firmware and test on the dev build I plan to put together.

I'll continue to monitor this thread though as it will be a bit before I get to making the dev build...perhaps someone will have the info I need before then and save me some work.

Maybe not. Maybe it is time to pause this path of NIC firmware updates and go back to basic diagnostics.

I would agree with you except since doing a clean install and then re-upgrading, the issue hasn't returned. Can't really run diagnostics on an issue that isn't occurring. Given that a clean install seems to have resolved the issue I think its safe to assume something went wrong with the original upgrade.

@apocalypticgoat if you can get the device, can you see anything with dmidecode i.e. say your nic is dev.ix0 then:

Code Select Expand

$sudo dmidecode /dev/ix0Should bring some more info.

This unfortunately did not expose the driver version.

Sorry I misled you there.

Code Select Expand

$sudo sysctl dev.ix0 should be helpful.

In my case it was dev.ix.0. This did yield a driver version of 4.0.1-k which from what I found is a driver provided by the kernel using the iflib framework.

Code Select Expand

dev.ix.0.fw_version: fw 2.11.3 nvm 1.00.0 Option ROM V1-b1458-p0 eTrack 0x8000048f
dev.ix.0.iflib.driver_version: 4.0.1-k
dev.ix.0.%driver: ix
4.0.1-k is at least 5 years old. I know this because I found a forum post from 2020 where someone mentioned that exact version number.

I checked this on 25.1 and it shows the same version number which means the driver remains unchanged..so maybe it wasn't a firmware/driver mismatch then?

After updating again it seems to be stable this time...so far. I'm wondering if something was buggered in the software somewhere.

When the previous update failed, I didn't have snapshots available so I reinstalled opnsense 24.1 from scratch and re-imported the backup I made from 24.1.12. This time during setup I made snapshots available.

I'm going to continue to monitor for any stability issues but I would like to update my cards firmware. I can't find much information on the 4.0.1-k driver and thus am unsure if the latest firmware is compatible with it or not. Does anyone have information on this?

There's a well known issue indeed: OPNsense doesn't develop Intel drivers for FreeBSD. 25.1 runs on FreeBSD 14.2, 24.7 was FreeBSD 14.1

Feel free to continue asking questions regarding driver development with FreeBSD/Intel people. I'm sure you'll have a great explanation on why you refuse to upgrade a card that needed 7 more firmware revisions after the one that you have installed.

First, Your post is incredible unhelpful and insulting. I'm well aware that Opnsense (and freebsd for that matter) don't develop the intel driver for these cards. I also know what Freebsd versions are running.

I posted here because I had no clue if this was a card issue, opnsense issue, freebsd issue or fw issue and there are plenty of people who use these cards and know more about it than I. Could it be a firmware/driver mismatch? Sure. It could just as easily be the card failing and something in the update triggers it...or perhaps a driver issue. Just because Opnsense doesn't make the driver doesn't mean I can't post here. First step was posting here to get information from others to determine if it was just me or others.

I did reach out to the freebsd forum and you know what? They wanted me to pull the driver version to determine what fw version to flash. I can't because in opnsense's implementation of FreeBSD, the driver version no longer shows when using sysctl (it apparently did in the 18.x days). Further, pkg doesn't even show that the intel driver is installed. Worse, the intel driver isn't even available. FreeBSD folks mentioned adding the FreeBSD_ports repo to get it but said that's likely not ideal (and I have no clue either).

As for it being "a well known issue", I don't doubt that but I can't find any information on it either. I did find some information on firmware/driver mismatch in general with these cards but that brings us back to I need to know what driver version is running so I can't get the appropriate firmware.

Tell me how to find the driver version number, I'll get the firmware updated to the compatible version and we can likely put this to bed.

I can't point to any offhand, but I have experienced NVM-to-driver mismatch issues with Linux, particularly with DPDK (which uses offloads). You could scan for potential issues in the release notes (they're cumulative). I've never bricked an Intel NIC with an upgrade, but naturally YMMV.

I spent some time looking at the change logs for both opnsense and Freebsd and I cannot find any mentions of the driver. The next thing I tried was pulling the driver version and then comparing it to the one used in 25.1. I found old posts (18.x days) where people would pull this information by using:

Code Select Expand

# sysctl -a | grep -E 'dev.(igb|ix|em).*.%desc:'
When I tried that, while it did correctly pull up my NIC, it did not show a driver number. I haven't tried doing that on the 25.1 version as of yet.

Lastly, I posted on the freebsd subreddit and they suggested doing a pkg-search for the driver but that came up empty as well.

Any suggestions?

The firmware version being reported by the card is 2.11.3. The latest version is 3.70 which puts me 7 versions behind. Is there any known issues between opnsense and the 500x firmware?

Hello,

I upgraded my installation from 24.7.12_4 to 25.1.2 and upon doing so, my NIC card became severely unstable. The LAN port would intermittently flap and when it wasn't flapping, IPv4 connectivity would work fine but IPv6 connectivity would not. On the IPv6 side, it would either not obtain an IPv6 address at all -or- if it did, it would not serve IPv6 addresses on the Lan side. If I ssh'd into into it I could IPv6 would resolve and respond normally.

I ended up reverting back to 24.7.12_4 and the system has stabilized. I checked the change logs for all versions between where I started and 25.1.2 and I didn't see a driver change that should have affected my NIC. Any idea's what may have gone wrong?

Specs:

Processor: Core i5-7400 CPU @ 3.00GHz
RAM:      12GB
Storage:  120GB kingston-sa400s37120g SSD
NIC:      intel x550-t2 Dual Port (Edit: I'm running this card with the link speed set for 2.5GB.)

Hi all,

So, I'm trying to get all devices to use pihole for dns. IPv4 is working perfectly. IPv6 not so much. I have input piholes ipv6 address into the DHCPv6 service page and while it is served, opnsense still includes its own IP address.

My assumption is that by supplying an address in DHCPv6, opnsense should not be advertising its own.

I've seen where people have suggested using Router advertainments as a work around (in my case set it to managed and supply the dns address there) and while that may work here...I'd really like to understand why DHCPv6 isn't behaving as expected.

Lastly, unbound is running on opnsense as pihole uses it as its upstream provider so blocking ports/disabling it is not an option.

DNS flow should look like this:

Device -> PiHole -> Opnsense -> Public DNS

But because Opnsense is providing its address for dns, pihole can get bypassed.

Anyone know if os-nut supports advanced configuration? Specifically looking for the battery delay option that the debian/rhel package of nut has.

So, I cannot disable nut in the general settings because even with the driver enabled it stops working.

Is there a configuration file I can edit for this plugin? In addition to fixing this issue, I also need to set a low battery delay.

My battery backup is technically border line overloaded and will complain about low battery during times of high load. One such occurrence caused opnsense to shutdown...which is weird because I was never on battery backup.

Hi,

I'm getting a re-occuring message in shell that I think is coming from nut:

UPS UPSName is unavailable

My opnsense box is a client only and serves no other machines. My ups is an APC smart-ups 1500RM. Nut is configured using the APCUPSD-driver.
Under general settings I do have nut enabled and all other settings at default.

It looks like the UPSName is coming from general settings. Can I disable nut since I'm using the APCUPSD driver and still get the auto shutdown action on battery low?

Not yet, usually we keep these on the development branch for at least one release, maybe since this is a relative small fix we can release it earlier, but if that's not the case you can still use patch after an update in the meantime.

Thanks for letting us know this fixes your issue, certainly helps in the release cycle.

Best regards,

Ad

Final Update: Its been 5 days since I applied the patch and the errors have not returned. At this point I'm comfortable declaring the patch the fix for my issue.

Understood on the release. I'll keep an eye on the patch notes and repatch after updates until I see it show up in the patch notes.

Sounds like a large log file, this https://github.com/opnsense/core/commit/71a8da452cca02412aab8906c2df0140cc434b28 might help, although the prefixes action will likely still take quite some time due to the size it needs to parse.


To apply the patch, the following command should do the trick:

Code Select Expand


opnsense-patch 71a8da4


Best regards,

Ad

Its been 24 hours since I've applied the patch and the memory exhaustion errors have not returned. Previously I was getting the exhausting error multiple times an hour, 24 hours a day. Since the patch was applied it has not returned and thus it would seem to indicate that the target of the patch was indeed my issue.

I plan to continue monitoring closely for a while to ensure the error does not return.

Is there an ETA on the update that will contain this patch?

I've applied the patch using the command provided. I'll monitor and report back.

Thanks!

I'm on 22.1.2.

My unit has 12GB of ram, all of which is available for opnsense to use.


I've sent it via the reporter as well but wanted to check here for more information.