Messages

The repo on github is back online. IMHO that won't be the solution:

https://github.com/AdguardTeam/AdGuardHome/issues/8561

All, pay attention to Patrick's note here ^ about "dnsbunker.org" being blocked by DOH lists.  It is also blocked by this one, if not others:

https://dbl.ipfire.org/lists/doh/domains.txt

So you might need to add an override.  I don't know if the firewall itself is affected by DNSBL policy (maybe depending on your setup), so may or may not be an issue for you.

This is a kind of ironic situation.  Hopefully hagezi can settle on a host that is NOT also a DNS provider.

One way one might also circumvent this problem is to set the option "Do not use the local DNS service as a nameserver for this system" under System->Settings->General. Then OPNsense should go upstream for all its DNS requests, instead of using the local Unbound DNS and its blocklists.

The repo on github is back online. IMHO that won't be the solution:

https://github.com/AdguardTeam/AdGuardHome/issues/8561

Indeed, it won't be. Hagezi himself recommends a different mirror for his repo and the new patch points to that one, IIRC. But until that patch ships in a release and folks have updated to it, at least their old blocklist entry will work again (at least until the next github suspension).

On a side note, I am very surprised that github doesn't have a mechanism to prevent certain repos that are frequently subject to reporting spam from being blocked without human review. But perhaps I'm expecting too much...

https://github.com/opnsense/core/pull/10709

Thank you!  Is this going out soon or should we apply it as a patch for now?

As another option, you could switch to advanced mode in the blocklist entry, clear all blocklist types and enter the new URLs from the patch directly.

Just a quick glance at a home user, with 10G backbone, but currently nearly pinning a core with only ~600Mbps file transfer.  This is a Intel i3-9100  Please @Zenarmor re-consider this decision.  I've promoted this product since inception, this is a big thorn I'm struggling with. 

Make a separate route for heavy downloading/uploading which does not go through Zenarmor. Use Zenarmor for browsing and IoT.

A potentially stupid question: How would you do you bypass Zenarmor (the free version) for certain traffic to the WAN, if you want your client to otherwise go through Zenarmor (e.g. for regular web browsing)?

These being said, your CPU should support 1 Gbps through Zenarmor.

My OPNsense box has a Celeron J6412, which apparently has about half the single-core performance of the i3-9100 and I'm still getting 1.1 Gbps on an iperf3 test between two local VLANs, so the OP's network speed seems slow indeed. In my case that's with i226-V NICs, which can do do 2.5 Gbps, and with Zenarmor disabled I can indeed reach 2.3 Gbps. I'd recommend to the OP to check the download speed with Zenarmor disabled.

IIRC some folks on the forums had some success in increasing network speed by setting some tunables. There also is a guide for that here, though with my NICs I never had to do any tuning.

Yesterday I finally sat down and determined why the Youtube app on my Android Google Pixel Tablet was stalling for certain videos and determined that deactivating Zenarmor (by disabling the interface my tablet is connected to) solved the problem.

Here's the scenario:
- My OPNsense router (26.7.1_1) uses an Intel Celeron J6412 CPU.
- With Zenarmor enabled (on that interface) my tablet had a network speed of about 230 Mbit/s down and 33 Mbit/s up, so plenty of bandwidth for a 1440p video.
- With Zenarmor enabled, the 1080p version of the video would only stall very occasionally, but the 1440p version would stall constantly. Looking at the "Statistics for nerds" in the Android Youtube app, the 1440p video would load initially load only 6s into the readahead buffer and then stall, when the buffer goes to zero, then load another 6s and so on. With the 1080p video it would initially load more and then add to the readahead buffer, before it drops to zero. (Sometimes though, it would stall the first time and then increase the size of the readahead buffer during the subsequent load, which gave it enough buffer to initiate a followup http request before the read buffer goes empty.)
- When I disable Zenarmor, the initial readahead buffer is larger by several seconds, apparently giving the Youtube app time to add to it and enlarge it, before it ever goes to zero, so no stalls.
- Note: This does not happen for ALL Youtube videos, but just for a small subset of them. I am assuming it depends on the location of the Youtube CDN server that serves that particular video to me and may even change over time as videos get moved or replicated to different CDN servers. FWIW the 1440p version of this particular video had the problem for me (location: San Francisco Bay Area, South Bay).

I understand that the Youtube app is obviously programmed in a "suboptimal" way, e.g. it doesn't increase the readahead buffer, when it stalls at the 1440p videos with Zenarmor enabled, and it doesn't allow to set a size for a minimum initial readahead buffer. Still I doubt that Google will do anything about that (though I will report this problem).

Yet in the meantime it seems that the only solution is to disable Zenarmor, at least in the free version. (The paid version has options to exclude clients or domains from Zenarmor's processing that might mitigate this problems.) Or buy a new router with a CPU that has much higher single-thread performance... (Probably not.) Did anyone ever encounter a similar problem and found a better solution?

AFAIK that's a very old RealTek NIC Chip used as Onboard NIC for a lot of devices and might be declared as EOL by the people who build the FreeBSD Kernel so you could check that and see if there is a solution available for those who want to use it anyway ?

Yes, it's old - that's why I'm using this machine as a firewall box rather than a general-purpose computer.
I suppose it's *possible* that the upstream devs went to the work of removing support for some RTL8111 flavors while leaving other RTL8111 flavors supported, but that seems implausible.

You could test, if native FreeBSD (15.1 IIRC) boots on your system (e.g. from a USB flash drive) with network drivers enabled. If it doesn't, then you'd need to take your problem upstream.

Does your system have a free PCIe slot? Then buy a cheap used NIC (e.g. on eBay) that is known to work well with FreeBSD and put it in your system. (I don't have such a list of NICs, but I'm using Intel i226-V on my OPNsense and it's been working without a problem.)

Once again, the great thing about standards is that there are so many of them. :/

But wait, there is more! I had a similar problem in my network that non-fqdn requests from my Windows 11 client to my TrueNAS server didn't work properly. The culprit here was that apparently Windows 11 uses mDNS by default. And the TrueNAS server had two network interfaces and returned two IPv4 adresses, but Windows picked the wrong one. I had to disable the mDNS server on TrueNAS to get this to work.

Wanted to drop in a status update. I'm not ready to declare victory quite yet, but this is the longest I've gone without an incident in quite a while. Possibly it was an issue with coreboot? Fingers crossed. I'll give it another week and then consider this resolved.

I am also running a Protectli (VP2420) with I226-V NICs and AMI-Bios and never had any stability problems. While I like the idea of coreboot as an open source solution, I have never used it on my two Protectli units and issues like the one you describe make me even less likely to try it in the future.

[o]

On my 26.7.1_1 installation of OPNsense I recently successfully ran the rules migration and switched to the new firewall and NAT rules UI. However there was one oddity that I noticed. For the Crowdsec plugin I am having TWO aliases for IPv4, crowdsec_blocklists and crowdsec_blacklists (and similarly two aliases for IPv6).

The "blacklists" alias appears in a floating rule, which I manually created some years ago, the blocklists alias appears in automatically generated rules (see attached pic). Apparently only the ipv4 crowdsec_blocklists alias is populated (see attached pic).

I'm wondering, what happened here. Did Crowdsec at some point in time change the naming scheme of their aliases from xxx_blacklists to xxx_blocklists? If so, I assume I could just delete my manual rules and delete the alias crowdsec_blacklists and crowdsec6_blacklists. Or does these aliases actually mean different things?

Thanks in advance for any insights.

Thanks for the info. I have them but they are not installed.

Yes, they are part of the OPNsense distribution, so everyone "has" them. But as long as they are not installed, they won't interfere with anything.

I was read though the upgrade notes that came up with the 26.7 upgrade. I read this:

The CPU microcode early loading has been known to be flaky on some setups. A fix is in the FreeBSD 15.1 boot loader code, but can only be reached by reinstall or manually updating the boot code of your system after the upgrade succeeded. If you want to be on the safe side during the upgrade itself please remove the plugin before proceeding.

What does it mean by "remove the plugin before proceeding"?. What plugin is it talking about?

Thanks

There are two plugins os-cpu-microcode-intel and os-cpu-microcode-amd and - depending on the CPU in your system - you can install the one you need to get updated microcode. It sounds though that you didn't install either, but I'd check to be on the safe side before upgrading your system. You can install/uninstall/see plugins under System -> Firmware -> Plugins.

just wanted to leave a short note because i ran in an issue after upgrading from 26.1.11 to 26.7.1 on a protectli vp2420.
after upgrading i noticed that the download throuput was roughly half of befor the upgrade.
i also noticed a increased rtt, rttd times during the speedtest.
first i blamed the internet provider of course ;) . as an old it vetran i have learnd that the root cause is always the network (just a joke).

turned out that following settings solved the problem:
net.isr.bindthreads: 1
net.isr.numthreads: 4
net.isr.maxthreads: 4


the original values:
net.isr.bindthreads: 0
net.isr.maxthreads: 1
net.isr.numthreads: 1

if i think about it, the original values dont make much sense for a 4 core system but worked for 26.1.11. However they did not for 26.7.1

keep in mind this is for a protectli vp2420 4 cores.

have a good time

t.

I also use a Protectli VP2420 as my OPNsense router and I did not notice a drop in speed after the upgrade to 26.7.1. In my default configuration (with ZenArmor enabled with native netmap driver) I am getting 1.1 Gbps in an internal iperf test (across subnets), with ZenArmor disabled, I am getting 2.33 Gbps in the same test. This is without any special tunables enabled, other than what ZenArmor configures by default: dev.netmap.ring_num=1024 and dev.netmap.buf_num=1000000.

So perhaps this depends on what configuration/plugins etc. one is running?

Code Select Expand

dmesg

after booting.

The bootloader update went without a hitch and so did the install of the os-cpu-microcode-intel plugin and subsequent reboot. However I couldn't find anything in the dmesg output that would point to the plugin doing something:

Code Select Expand

---<<BOOT>>---
Copyright (c) 1992-2025 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 15.1-RELEASE-p1 stable/26.7-n283674-12334a596709 SMP amd64
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
[1] VT(vga): resolution 640x480
[1] CPU: Intel(R) Celeron(R) J6412 @ 2.00GHz (1996.80-MHz K8-class CPU)
[1]  Origin="GenuineIntel"  Id=0x90661  Family=0x6  Model=0x96  Stepping=1
[1]  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
[1]  Features2=0x4ff8ebbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,RDRAND>
[1]  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
[1]  AMD Features2=0x101<LAHF,Prefetch>
[1]  Structured Extended Features=0x2394a2c3<FSGSBASE,TSCADJ,FDPEXC,SMEP,ERMS,NFPUSG,PQE,RDSEED,SMAP,CLFLUSHOPT,CLWB,PROCTRACE,SHA>
[1]  Structured Extended Features2=0x18400124<UMIP,WAITPKG,GFNI,RDPID,MOVDIRI,MOVDIR64B>
[1]  Structured Extended Features3=0xfc000400<MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,CORE_CAP,SSBD>
[1]  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
[1]  IA32_ARCH_CAPS=0x20c6b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,MDS_NO>
[1]  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
[1]  TSC: P-state invariant, performance statistics
[1] real memory  = 17179869184 (16384 MB)
[1] avail memory = 16488919040 (15725 MB)
[1] Event timer "LAPIC" quality 600
[1] ACPI APIC Table: <ALASKA A M I >
[1] WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1)
[1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
[1] FreeBSD/SMP: 1 package(s) x 4 core(s)
[1] random: registering fast source Intel Secure Key Seed
[1] random: fast provider: "Intel Secure Key Seed"
[1] random: unblocking device.
[1] ioapic0 <Version 2.0> irqs 0-119
[1] Launching APs: 3 1 2
[1] random: entropy device external interface
[1] wlan: mac acl policy registered
[1] kbd0 at kbdmux0
[1] WARNING: Device "spkr" is Giant locked and may be deleted before FreeBSD 16.0.
[1] efirtc0: <EFI Realtime Clock>
[1] efirtc0: registered as a time-of-day clock, resolution 1.000000s
[1] smbios0: <System Management BIOS> at iomem 0x78a3e000-0x78a3e017
[1] smbios0: Entry point: v3 (64-bit), Version: 3.3
[1] aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS,SHA1,SHA256>
[1] acpi0: <ALASKA A M I >
[1] acpi0: Power Button (fixed)
[1] cpu0: <ACPI CPU> on acpi0
[1] hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
[1] Timecounter "HPET" frequency 19200000 Hz quality 950
[1] Event timer "HPET" frequency 19200000 Hz quality 550
[1] Event timer "HPET1" frequency 19200000 Hz quality 440
[1] Event timer "HPET2" frequency 19200000 Hz quality 440
[1] Event timer "HPET3" frequency 19200000 Hz quality 440
[1] Event timer "HPET4" frequency 19200000 Hz quality 440
[1] atrtc1: <AT realtime clock> on acpi0
[1] atrtc1: Warning: Couldn't map I/O.
[1] atrtc1: registered as a time-of-day clock, resolution 1.000000s
[1] Event timer "RTC" frequency 32768 Hz quality 0
[1] attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
[1] Timecounter "i8254" frequency 1193182 Hz quality 0
[1] Event timer "i8254" frequency 1193182 Hz quality 100
[1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
[1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
[1] pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
[1] pci0: <ACPI PCI bus> on pcib0
[1] vgapci0: <VGA-compatible display> port 0x3000-0x303f mem 0x6000000000-0x6000ffffff,0x4000000000-0x400fffffff at device 2.0 on pci0
[1] vgapci0: Boot video device
[1] xhci0: <Intel Elkhart Lake USB 3.1 controller> mem 0x6001100000-0x600110ffff at device 20.0 on pci0
[1] xhci0: 32 bytes context size, 64-bit DMA
[1] xhci0: xECP capabilities <PROTO,PROTO,VEND(c0),LEGACY,VEND(c6),VEND(c7),VEND(c2),DEBUG,VEND(c3),VEND(c4),VEND(ce),VEND(c8),VEND(c9),VEND(ca),VEND(cb),VEND(cc),VEND(cd)>
[1] usbus0 on xhci0
[1] usbus0: 5.0Gbps Super Speed USB v3.0
[1] pci0: <memory, RAM> at device 20.2 (no driver attached)
[1] pci0: <simple comms> at device 22.0 (no driver attached)
[1] ahci0: <Intel Elkhart Lake AHCI SATA controller> port 0x3090-0x3097,0x3080-0x3083,0x3060-0x307f mem 0x80800000-0x80801fff,0x80803000-0x808030ff,0x80802000-0x808027ff at device 23.0 on pci0
[1] ahci0: AHCI v1.31 with 2 6Gbps ports, Port Multiplier not supported
[1] ahcich0: <AHCI channel> at channel 0 on ahci0
[1] ahcich1: <AHCI channel> at channel 1 on ahci0
[1] pci0: <serial bus> at device 25.0 (no driver attached)
[1] pci0: <simple comms> at device 25.2 (no driver attached)
[1] sdhci_pci0: <Generic SD HCI> mem 0x6001119000-0x6001119fff at device 26.0 on pci0
[1] sdhci_pci0: 1 slot(s) allocated
[1] mmc0: <MMC/SD bus> on sdhci_pci0
[1] pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
[1] pci1: <ACPI PCI bus> on pcib1
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x80600000-0x806fffff,0x80700000-0x80703fff at device 0.0 on pci1
[1] igc0: EEPROM V2.17-0 eTrack 0x80000303
[1] igc0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc0: Using 4 RX queues 4 TX queues
[1] igc0: Using MSI-X interrupts with 5 vectors
[1] igc0: Ethernet address: 64:62:66:23:15:af
[1] igc0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] pcib2: <ACPI PCI-PCI bridge> at device 28.1 on pci0
[1] pci2: <ACPI PCI bus> on pcib2
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x80300000-0x803fffff,0x80400000-0x80403fff at device 0.0 on pci2
[1] igc1: EEPROM V2.17-0 eTrack 0x80000303
[1] igc1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc1: Using 4 RX queues 4 TX queues
[1] igc1: Using MSI-X interrupts with 5 vectors
[1] igc1: Ethernet address: 64:62:66:23:15:b0
[1] igc1: netmap queues/slots: TX 4/1024, RX 4/1024
[1] pcib3: <ACPI PCI-PCI bridge> at device 28.2 on pci0
[1] pci3: <ACPI PCI bus> on pcib3
[1] igc2: <Intel(R) Ethernet Controller I226-V> mem 0x80000000-0x800fffff,0x80100000-0x80103fff at device 0.0 on pci3
[1] igc2: EEPROM V2.17-0 eTrack 0x80000303
[1] igc2: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc2: Using 4 RX queues 4 TX queues
[1] igc2: Using MSI-X interrupts with 5 vectors
[1] igc2: Ethernet address: 64:62:66:23:15:b1
[1] igc2: netmap queues/slots: TX 4/1024, RX 4/1024
[1] pcib4: <ACPI PCI-PCI bridge> at device 28.4 on pci0
[1] pci4: <ACPI PCI bus> on pcib4
[1] igc3: <Intel(R) Ethernet Controller I226-V> mem 0x7fd00000-0x7fdfffff,0x7fe00000-0x7fe03fff at device 0.0 on pci4
[1] igc3: EEPROM V2.17-0 eTrack 0x80000303
[1] igc3: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc3: Using 4 RX queues 4 TX queues
[1] igc3: Using MSI-X interrupts with 5 vectors
[1] igc3: Ethernet address: 64:62:66:23:15:b2
[1] igc3: netmap queues/slots: TX 4/1024, RX 4/1024
[1] isab0: <PCI-ISA bridge> at device 31.0 on pci0
[1] isa0: <ISA bus> on isab0
[1] hdac0: <Intel Elkhart Lake HDA Controller> mem 0x6001110000-0x6001113fff,0x6001000000-0x60010fffff at device 31.3 on pci0
[1] pci0: <serial bus> at device 31.5 (no driver attached)
[1] battery0: <ACPI Control Method Battery> on acpi0
[1] acpi_button0: <Sleep Button> on acpi0
[1] acpi_button1: <Power Button> on acpi0
[1] acpi_tz0: <Thermal Zone> on acpi0
[1] uart: ns8250: UART FCR is broken (0x1)
[1] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
[1] uart0: console (115200,n,8,1)
[1] acpi_syscontainer0: <System Container> on acpi0
[1] acpi_syscontainer1: <System Container> on acpi0
[1] atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0
[1] atrtc0: Warning: Couldn't map I/O.
[1] atrtc0: registered as a time-of-day clock, resolution 1.000000s
[1] atrtc0: Can't map interrupt.
[1] est0: <Enhanced SpeedStep Frequency Control> on cpu0
[1] cpufreq0: <CPU frequency control> on cpu0
[1] cpufreq1: <CPU frequency control> on cpu1
[1] cpufreq2: <CPU frequency control> on cpu2
[1] cpufreq3: <CPU frequency control> on cpu3
[1] Timecounter "TSC" frequency 1996802797 Hz quality 1000
[1] Timecounters tick every 1.000 msec
[1] ugen0.1: <Intel XHCI root HUB> at usbus0
[1] uhub0 on usbus0
[1] uhub0: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
[1] ZFS filesystem version: 5
[1] ZFS storage pool version: features support (5000)
[1] mmcsd0: 16GB <MMCHC AJTD4R 0.6 SN 3F2CBEA6 MFG 08/2023 by 21 0x0000> at mmc0 200.0MHz/8bit/8192-block
[1] mmcsd0boot0: 4MB partition 1 at mmcsd0
[1] mmcsd0boot1: 4MB partition 2 at mmcsd0
[1] mmcsd0rpmb: 4MB partition 3 at mmcsd0
[1] hdacc0: <Intel Elkhart Lake HDA CODEC> at cad 2 on hdac0
[1] hdaa0: <Intel Elkhart Lake Audio Function Group> at nid 1 on hdacc0
[1] pcm0: <Intel Elkhart Lake (HDMI/DP 8ch)> at nid 4 on hdaa0
[1] ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0: <Protectli 1TB M.2 SBFM61.5> ACS-4 ATA SATA 3.x device
ada0: Serial Number 511240308075000055
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 976762MB (2000409264 512 byte sectors)
[1] Trying to mount root from zfs:zroot/ROOT/default []...
[2] uhub0: 16 ports with 16 removable, self powered
[9] CPU: Intel(R) Celeron(R) J6412 @ 2.00GHz (1996.80-MHz K8-class CPU)
[9]  Origin="GenuineIntel"  Id=0x90661  Family=0x6  Model=0x96  Stepping=1
[9]  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
[9]  Features2=0x4ff8ebbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,RDRAND>
[9]  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
[9]  AMD Features2=0x101<LAHF,Prefetch>
[9]  Structured Extended Features=0x2394a2c3<FSGSBASE,TSCADJ,FDPEXC,SMEP,ERMS,NFPUSG,PQE,RDSEED,SMAP,CLFLUSHOPT,CLWB,PROCTRACE,SHA>
[9]  Structured Extended Features2=0x18400124<UMIP,WAITPKG,GFNI,RDPID,MOVDIRI,MOVDIR64B>
[9]  Structured Extended Features3=0xfc000400<MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,CORE_CAP,SSBD>
[9]  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
[9]  IA32_ARCH_CAPS=0x14020c6b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,MDS_NO>
[9]  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
[9]  TSC: P-state invariant, performance statistics
[13] igc0: link state changed to UP
[13] igc1: link state changed to UP
[16] ichsmb0: <Intel Elkhart Lake SMBus controller> port 0xefa0-0xefbf mem 0x6001118000-0x60011180ff at device 31.4 on pci0
[16] smbus0: <System Management Bus> on ichsmb0
[17] acpi_wmi0: <ACPI-WMI mapping> on acpi0
[17] acpi_wmi0: cannot find EC device
[17] acpi_wmi1: <ACPI-WMI mapping> on acpi0
[17] acpi_wmi1: cannot find EC device
[17] acpi_wmi1: Embedded MOF found
[17] acpi_wmi2: <ACPI-WMI mapping> on acpi0
[17] acpi_wmi2: cannot find EC device
[17] acpi_wmi2: Embedded MOF found
[19] lo0: link state changed to UP
[19] coretemp0: <CPU On-Die Thermal Sensors> on cpu0
[23] load_dn_sched dn_sched FIFO loaded
[23] load_dn_sched dn_sched QFQ loaded
[23] load_dn_sched dn_sched RR loaded
[23] load_dn_sched dn_sched WF2Q+ loaded
[23] load_dn_sched dn_sched PRIO loaded
[23] load_dn_sched dn_sched FQ_CODEL loaded
[23] load_dn_sched dn_sched FQ_PIE loaded
[23] load_dn_aqm dn_aqm CODEL loaded
[23] load_dn_aqm dn_aqm PIE loaded
[23] ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled
[24] igc1: link state changed to DOWN
[24] vlan0: changing name to 'vlan0.1010'
[24] vlan1: changing name to 'vlan0.1020'
[24] vlan2: changing name to 'vlan0110'
[25] igc0: link state changed to DOWN
[25] wg0: link state changed to UP
[25] tun0: changing name to 'zen0'
[28] igc1: link state changed to UP
[28] vlan0.1020: link state changed to UP
[28] vlan0110: link state changed to UP
[28] vlan0.1010: link state changed to UP
[28] igc0: link state changed to UP
[32] tun1: link state changed to UP
[32] tun1: changing name to 'tailscale0'
[37] 595.221991 [ 805] iflib_netmap_config      txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048
[38] 595.947963 [ 805] iflib_netmap_config      txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048
[38] 595.981494 [ 805] iflib_netmap_config      txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048
[38] 596.014972 [ 805] iflib_netmap_config      txr 4 rxr 4 txd 1024 rxd 1024 rbufsz 2048
[38] igc1: link state changed to DOWN
[38] vlan0.1020: link state changed to DOWN
[38] vlan0110: link state changed to DOWN
[38] vlan0.1010: link state changed to DOWN
[42] igc1: link state changed to UP
[42] vlan0.1020: link state changed to UP
[42] vlan0110: link state changed to UP
[42] vlan0.1010: link state changed to UP


FWIW I ran the command

Code Select Expand

x86info -a | grep -i micro and it told me that the microcode version of my Intel Celeron J6412 CPU is 0x000000000000001a. Unfortunately x86info uninstalls, when I uninstall the plugin, so I couldn't check the microcode version without it installed.

So does this mean that there is a problem with the plugin? If so, how can I trace down the root cause?

It won't cause any downtime. You do not strictly need to reboot the system, you know?

Not strictly perhaps, but then I might as well test the change right away and make sure the system comes back up. Otherwise, if the system fails to boot at a later time - say after the next OPNsense update/upgrade - I'm dealing with multiple potential root causes. So I'd rather keep it simple and straightforward.

Thanks to everyone working on OPNsense or otherwise helping with the project. Just donated 50 USD to the project.