Messages

Well,
Try a manual install. Does it take or fail?

I think early ucode loads can be blocked by a bios/eufi ucode process because the 1st loading was still in ioctl which is a kernel operation, and loader.conf was blocked at that point. 100% possible.

Production firewall?
Then schedule a maintenance window and run the loading from rc.local.
We're only talking about reboot times.
If the manual loading works with rc.local, then it's a ucode timing issue, leave it this way for now.
If the manual loading fails then it's something else more non-trivial.
If the manual test fails, just chmod -x rc.local and change loader.conf cpu_microcode_load back to "YES", then wait for support.

But let's clarify where to put a boot script, OPNsense is a bit "odd".
https://docs.opnsense.org/development/backend/autorun.html

stick the rc.local (or whatever you name it) in the "early" directory. I believe the daemon runs them per #, so name script 50-rc.local, etc.
 /usr/local/etc/rc.syshook.d/early/

Some more reading about alder lake with bios/uefi with freeBSD.
loader.conf may be too early to try and push a ucode update.

as a test, remove the load entries from loader.conf (or change to cpu_microcode_load="NO")

rc.local
#!/bin/sh
sleep 10
/usr/sbin/cpucontrol -m /dev/cpuctl0 /boot/firmware/intel-ucode.bin
/usr/sbin/cpucontrol -m /dev/cpuctl1 /boot/firmware/intel-ucode.bin

chmod +x /etc/rc.local

although I have not yet found Intel documentation explicitly confirming the exact revision mapping.

100% Intel has it. meyergru was right, that cpu is a 0x80. I was likely provided bad info for the mapping of desktop vs mobile variant (see below).
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/commit/b24397c3611f5b0a7ccb3071df99ba596721d82b#diff-1dfe853ac13a3d80cb5ef06b3c030342fb367f6f6ad6bdb2328e48c47ec16e08



Apparently, the i3-1215U is a "mobile" cpu package, period. However, the fusing is different, notice they call the 0x80 the "desktop" fusing and the 0x40 is the "mobile" fusing.

(for this i3-1215U)
mask = "package"/"fusing"
0x40 = mobile/mobile
0x80 = mobile/desktop

/////////////////////////////////////////
Why there are multiple platform IDs (.40 vs .80)
From Intel microcode layout:
The same CPU model (06-9A-04)
can run in different platform configurations
selected via MSR IA32_PLATFORM_ID (0x17)

So Intel splits microcode into:

Platform ID mask   Meaning
0x40                          mobile / low-power configuration
0x80                          desktop / higher-power configuration

///////////////////////////////////////

A good read
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/microcode-update-guidance.html

I agree with fastboot.
Everything points to cpu variant fusing ID 7 (0x80 mask)

The iucode testing I did shows the newer rev code for this cpu(ID 7). It's listed in the bin and in the .80 file.

Here's some new info, please verify.
According to some docs the klm cpuctl needs to be loaded BEFORE a microcode can be installed by cpucontrol utility.

1) boot normally, try kldstat | grep cpuctl , is that klm loaded?
1a) if that klm is not loaded, then kldload cpuctl (it may not actually be loaded at boot time, or in time for cpucontrol)
2) then try cpucontrol -u /dev/cpuctl0 /boot/firmware/intel-ucode.bin
3) then verify it installed on that cpu
cpucontrol -m 0x8B /dev/cpuctl0
expecting to see MSR 0x8B: 0x00000000 0x0000043b
microcode revision = 0x043b

remember, you have /dev/cpuctl0 and /dev/cpuctl1

If this manual process fails, then something else is preventing the install of the code onto the device, bios/uefi is likely culprit.

All,
I downloaded the latest _1 ucode pkg, and iucode_tool pkg to my ubuntu.

Some interesting results.
I am using gemini ai for help.

I then do some more asking about the exact cpu model, ai now says that mobile cpu is a pf_mask 0x80, not the 0x40 file.
Hmmmmmm.

Ok, so i turn the tool onto the 40 and 80 and bin files. All files indeed handle the 06-9a-04 (cpuid) but have different platform ID's , 6 for 0x40 and 7 for 0x80.

The 0x40 only has ucode 2025-07-10 rev 0x000c (single cpuid)
The 0x80 has ucode 2025-10-12 rev 0x043b (which covers two cpuid's)


So, need to verify if the info found in early posts was correct or not, mobile cpu is x80(pf_mask decimal 7) or a x40(pf_mask decimal 6).

Or, the actual cpu is a real 0x40 (not a mobile cpu), but this would not make sense since the installed is a 0x432.

I would start looking at actual cpu make/model/masks, etc etc. From there I would suspect the bios/uefi is blocking cpucontrol?

To be sure what cpu fusing you have (mask 7 or 6), need to read  IA32_PLATFORM_ID

To read IA32_PLATFORM_ID, ....... there's a way with cpuctl klm ........ stay tuned...

ok, update:
if this klm is not there then you need to copy it over from a reg bsd 14.3 OS.
example:
kldload cpuctl
ls /dev/cpuctl*
cpucontrol -m 0x17 /dev/cpuctl0

This will print something like:
MSR 0x17: high=0x00000000 low=0x10000000

make script and run it
#!/usr/local/bin/bash
output=$(cpucontrol -m 0x17 /dev/cpuctl0)
high=$(echo "$output" | awk -F' ' '{for(i=1;i<=NF;i++) if($i ~ /high=/) print $i}' | cut -d= -f2)
low=$(echo "$output" | awk -F' ' '{for(i=1;i<=NF;i++) if($i ~ /low=/) print $i}' | cut -d= -f2)
value=$(( (high << 32) | low ))
platform_id=$(( (value >> 52) & 7 ))
echo "$platform_id"

The final output is a digit 0-7





 

Well, we can look into the .40 and .80 files using iucode_tool utility, it will show us what ucode versions exist there. What you have now may be the latest.
Or maybe the bin is missing stuff?

The tool is not on freeBSD repo, but it is on Ubuntu repo, so I will get to look at it tomorrow.

4 miles on limited power of wifi, on flat ribbon antenna?
A well tuned yagi probably will struggle. Do those wifi devices provide dBm info (Tx and Rx), I am curious what level the signal is at.

But using that diagram, my guess, an ARP issue is presenting itself. When the problem happens does the ARP tables look ok?

Is that bridge doing actual bridging or proxy-ARP'ing ?

An interface is an interface. If the device has a builtin wifi device, then it can be used as an interface. Wifi can be AP, ad-hoc, bridge.

So what's the question?

Does the firewall itself have internet access?
Also, since you are a beginner I would first try opnsense on the actual hardware, except if you already have proxmox experience.

.........  and, ....... at least read all the official OPNsense documentation, as there's plenty to read.

Stop OPNsense FW services and run your windows test through the router, what speed does it get.

I think for anything above 1Gb you need to tune the device as a fast router. Anything beyond just router and it will slow things down.

You can also test through the fw from a host on port A to a host on port B. A ping test with various sizes, ping -s or ping -l, and record the response time, from there it's just math (use AI bot). You can also load up bandwidth by sending large sums of UDP from A to B.

This is from my std install of v14.3 (not opnsense). The _1 ucode pkg is not in Quarterly yet, but it is in Latest.




download from Latest.
curl -O https://pkg.freebsd.org/FreeBSD%3A14%3Aamd64/latest/All/Hashed/cpu-microcode-intel-20260512_1~a2a4a2e6e1.pkg
pkg install cpu-microcode-intel-20260512_1~a2a4a2e6e1.pkg

All fixed??

A bit convoluted to follow.
_1 has a last import of "new" on June 5 2026 (https://www.freshports.org/sysutils/cpu-microcode-intel/)

There seems to be two builds for 14 latest
https://ports.freebsd.org/cgi/ports.cgi?stype=pkg&query=sysutils/cpu-microcode-intel

We need more info.
Is the actual new pkg installed? Does the loader conf say to install the bin? What size is the ucode bin file? Is the .80 file there?

As already mentioned, make sure all the layer-1 stuff is good end-to-end.
Verify config on both ends.

Last resort, inquiry with vendor for possible grayware.