Messages

[First, I am not planning to risk any outage, nor am I willing to accept one at this point.]

Thanks for the suggestion.

I understand the reasoning behind the test, but there are a couple of reasons why I'm hesitant to try it on this particular system.

First, I am not planning to risk any outage, nor am I willing to accept one at this point. While a reboot itself is not a major issue, the proposed test involves changing the microcode loading path and boot behaviour rather than simply observing the existing system state.

Second, the original issue I reported was a packaging problem in FreeBSD. That issue has now been confirmed and fixed upstream. The remaining question is why this specific platform still does not receive a microcode update even though:

- the correct 06-9a-04.80 split file is now present
- IA32_PLATFORM_ID indicates platform ID 7 (0x80)
- newer microcode revisions appear to exist for this CPU family

At this point I'm not yet convinced that the root cause is a timing issue. The current evidence only shows that the microcode is not being applied, not why.

Before testing alternative loading mechanisms, I would prefer feedback from the FreeBSD maintainer of the microcode package. If there is a specific diagnostic procedure recommended from the FreeBSD side, I'll be happy to follow it.

For now I'd rather avoid changing the microcode loading mechanism on a production system and potentially introducing a second variable while the original issue is still under investigation by the maintainer. => See the Bug Report

[Wichtiger Hinweis zur Nutzung:]

UPDATE_AVAILABLE: Current version: OPNsense 26.4.1, Available version: OPNsense 26.1.10. Irgendwie funktioniuert es nicht mehr..

Mit Verlaub: So sollte man keinen Support erwarten.

Ein einzelnes "funktioniert nicht mehr" zusammen mit einer Ausgabe, die offensichtlich zwei unterschiedliche Versionsstände zeigt, ist keine brauchbare Fehlerbeschreibung. Business Version != FREE Version

Wenn man Hilfe möchte, sollte man zumindest die verwendeten Befehle, deren Ausgaben und die eigene Umgebung nennen.  Damit hätte sich innerhalb weniger Sekunden erkennen lassen, was tatsächlich verglichen wird.

Mein Script macht genau das, wofür es geschrieben wurde. Aus der geposteten Ausgabe allein lässt sich weder ein Fehler im Script noch ein Defekt nachweisen. Sie zeigt lediglich, dass die installierte Version und die vom abgefragten Repository gelieferte Version voneinander abweichen.

Wer einen Fehler vermutet, sollte zunächst nachvollziehen, wie die Ausgabe zustande kommt, bevor er pauschal behauptet, etwas würde nicht mehr funktionieren. Manchmal sagt meine Glaskugel auch einfach: Nein.

Code Select Expand

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

PKG_NAME="opnsense"

CURRENT_VERSION=$(opnsense-version 2>/dev/null | awk '{print $2}')
AVAILABLE_VERSION=$(pkg rquery '%v' "$PKG_NAME" 2>/dev/null)

if [ -z "$CURRENT_VERSION" ]; then
    echo "UNKNOWN: Could not determine installed OPNsense version"
    exit 3
fi

if [ -z "$AVAILABLE_VERSION" ]; then
    echo "UNKNOWN: Could not determine repository version for $PKG_NAME"
    exit 3
fi

if [ "$CURRENT_VERSION" = "$AVAILABLE_VERSION" ]; then
    echo "NO_UPDATE: Current version: OPNsense $CURRENT_VERSION"
    exit 0
fi

# FreeBSD/pkg-kompatibler Versionsvergleich
if pkg version -t "$CURRENT_VERSION" "$AVAILABLE_VERSION" >/dev/null 2>&1; then
    CMP=$(pkg version -t "$CURRENT_VERSION" "$AVAILABLE_VERSION")

    case "$CMP" in
        "<")
            echo "UPDATE_AVAILABLE: Current version: OPNsense $CURRENT_VERSION, Available version: OPNsense $AVAILABLE_VERSION"
            exit 1
            ;;
        ">")
            echo "VERSION_MISMATCH: Installed OPNsense $CURRENT_VERSION is newer than repository version OPNsense $AVAILABLE_VERSION"
            exit 2
            ;;
        "=")
            echo "NO_UPDATE: Current version: OPNsense $CURRENT_VERSION"
            exit 0
            ;;
        *)
            echo "UNKNOWN: Unexpected comparison result: $CMP"
            exit 3
            ;;
    esac
else
    echo "UNKNOWN: Version comparison failed: installed=$CURRENT_VERSION repository=$AVAILABLE_VERSION"
    exit 3
fi

Wichtiger Hinweis zur Nutzung:

Dieses Script wird auf eigene Gefahr von Anwendern, Anwenderinnen, Anwendenden, Anwender*innen, Anwender und sonstigen scriptnutzenden Personen verwendet. Für Schäden an Hardwarern, Softwareinnen, Firmwarenden, Netzwerkern, Netzwerkenden oder sonstigen digital arbeitenden Wesen wird keinerlei Haftung übernommen.

Bitte konsultieren Sie vor der Verwendung Ihren Arzt, Ihre Ärztin, Ihr Ärztendenwesen, Ihren Apotheker, Ihre Apothekerin, Ihre Apothekerndenfachkraft, Ihren Tierpfleger, Ihre Tierpflegerin, Ihre Tierpflegefachperson sowie gegebenenfalls Ihren Systemadministrator, Ihre Systemadministratorin oder Ihre systemadministrierenden Fachkräfte.

Sollten nach der Nutzung Symptome wie "geht nicht", "funktioniert nicht", "habe nichts geändert", "ist plötzlich kaputt", "war gestern noch gut" oder "das Script ist schuld" auftreten, wenden Sie sich bitte umgehend an qualifizierte Troubleshooter, Troubleshooterinnen, Troubleshootende oder anderweitig fehlersuchende Personen.

Mit der Ausführung erklären Sie sich einverstanden, dass Sie die Ausgabe lesen, verstehen, interpretieren und gegebenenfalls darüber nachdenken. Sollten Sie dazu nicht in der Lage sein, lassen Sie das Script bitte durch eine fachkundige Person, Fachkraft, Fachperson oder fachkraftausübende Person Ihres Vertrauens bedienen.

Ich glaube, hier reden wir gerade über zwei unterschiedliche Setups. 🙂

Das Vigor 167 läuft im Bridge-Modus und die OPNsense macht die PPPoE-Einwahl selbst. In dem Fall gibt es ja eigentlich kein geroutetes Transfernetz zwischen DrayTek und OPNsense und auch kein Gateway auf dem DrayTek, das auf dem WAN der OPNsense eingetragen werden müsste. Nebenher kann man dann tolles Doppel-NAT machen... Kann man machen, aber man kann es sich auch ersparen. Denn dafür hat er alles nötige da...

Die einzige IP die das Vigor Modem hat ist die Management IP. Und hier gibt man einfach dem physischen Interface an der OPNsense, wo das Modem dran hängt, eine /30 aus dem Mgmt Netz...

Die eigentliche Frage des OP war für mich eher, wie er möglichst einfach von seiner alten Installation auf die neue Protectli migrieren kann.

Ich würde ganz klar neu installieren und von Scratch konfigurieren. Bei dem ewig wiederkerhrenden mach doch mal "ANY ANY" auf, bekomme ich ehrlich gesagt Bauchschmerzen.

Eine Standardkonfiguration für eine Sense ist in wenigen Minuten eingerichtet. Fine Tuning kommt später...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

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

Thanks for looking into it.

The IA32_PLATFORM_ID result seems to confirm that 0x80 is indeed the relevant variant for this CPU, which was very helpful.

As for the manual loading tests, I'd rather wait for feedback from the FreeBSD side first. This is a production firewall and microcode loading happens very early in the boot process, so I'm not particularly eager to start experimenting with manual updates, loader changes or alternative loading paths without a recommendation from the maintainer of the FreeBSD microcode package.

At this point the original packaging issue is fixed, the correct .80 file is present, and the remaining question seems to be why the update is still not being applied on this specific platform. I might also get in touch with Protectli, as usually their support is superb.

Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

Are you sure there is a microcode update applicable to your CPU? Is there any way to check this with e.g. Intel docs?

I do not have Intel documentation directly mapping revisions to this specific CPU.

However, there is fairly strong evidence that newer microcode exists for CPUID 06-9a-04:

- Linux systems with the same CPU (Intel i3-1215U) have been observed running microcode 0x43a.
- My system remains on 0x432.
- After upgrading to cpu-microcode-intel-20260512_1, the package now provides both 06-9a-04.40 and 06-9a-04.80 split files.
- Reading IA32_PLATFORM_ID yields platform ID 7, which appears to correspond to platform mask 0x80.

For reference:

# cpucontrol -m 0x17 /dev/cpuctl0
MSR 0x17: 0x001c0000 0x00000000

which decodes to platform ID 7.

So at this point there seems to be strong evidence that a newer microcode should be applicable to this CPU, although I have not yet found Intel documentation explicitly confirming the exact revision mapping.

Hi,

I checked IA32_PLATFORM_ID:

cpucontrol -m 0x17 /dev/cpuctl0
MSR 0x17: 0x001c0000 0x00000000

Using bits 52:50:

(0x001c000000000000 >> 50) & 7 = 7

So this CPU appears to have platform ID 7, which corresponds to platform mask 0x80.

That means the relevant file should be 06-9a-04.80, not .40.

The .80 file is now present after cpu-microcode-intel-20260512_1, but the system still stays on microcode 0x432 and reports:

CPU microcode: no matching update found

Quick update:
After upgrading to cpu-microcode-intel-20260512_1, the new split files are now present:

/usr/local/share/cpucontrol/06-9a-04.40
/usr/local/share/cpucontrol/06-9a-04.80

So the FreeBSD ucode-split fix from PR 295351 is clearly working as intended.

However, after rebooting, my system still reports: CPU microcode: no matching update found
and remains on: Microcode version: 0x432

System details:
Protectli VP6630
Dasharo (coreboot+UEFI) v0.9.0
Intel Core i3-1215U (CPUID 06-9a-04)

I have updated the FreeBSD bug report with the new findings. So the original packaging issue is fixed, but there still appears to be an additional issue affecting this specific system.

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?

The information is already available both in this thread and in the FreeBSD bug report.

For completeness:

- cpu-microcode-intel-20260512 is installed
- cpu_microcode_load="YES" and cpu_microcode_name="/boot/firmware/intel-ucode.bin" are configured
- intel-ucode.bin exists and is 16 MB
- CPU is an i3-1215U (CPUID 06-9a-04)
- current microcode remains 0x432
- boot still reports "CPU microcode: no matching update found"

However, Joseph Mingrone pointed out that the fix discussed in PR 295351 was only included starting with cpu-microcode-intel-20260512_1.

My system is currently still on 20260512, so I haven't  actually tested the fixed package yet.

Once OPNsense ships the _1 revision, I'll test again and report back.

Quick update:

The FreeBSD fix has now been merged:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

and OPNsense has already shipped an updated cpu-microcode-intel package (20260512).

However, after upgrading and rebooting, my system still reports:

CPU microcode: no matching update found

The system is a Protectli VP6630 with an Intel i3-1215U running Dasharo/coreboot 0.9.0.

So the original FreeBSD issue was real and has been fixed upstream, but my specific Alder Lake R0 system still does not appear to receive a microcode update. I have added the new findings to the FreeBSD bug report for further investigation.

Will be interesting to see what the root cause turns out to be.

Not every thread warrants a comment

Rest assured the firmware updates will be coming once they're available for FreeBSD

Awesome.

Good catch regarding the mobile vs desktop R0 variants. You are right, the i3-1215U is a mobile Alder Lake R0 CPU, so .40 should indeed be the correct platform variant, not .80.

So my original assumption about a missing .80 blob was likely wrong.

However, the interesting part still seems to be:

dmesg:
CPU microcode: no matching update found

combined with:

• installed cpu-microcode-intel package
• stale-looking revision 0x432
• newer revisions apparently existing upstream/Linux side

So there still appears to be some kind of matching/loading issue on this platform, even if the root cause is not the missing .80 variant.

I have opened a FreeBSD bug report for further investigation:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

You missed my other point. Did you 100% verify that your device has the exact CPU that is stated on the box, or did they somehow solder in a "desktop" variant.

On the working group page (https://reviews.freebsd.org/D57046), they call out affected cpu families, but the Alder Lake R0 is not named. And, if I am reading it right, it looks like the .40 is not being fixed in any way, but it does look like a fix for the missing .80 is there. So I am still curious.

Also possible, the coders flipped over .40's and .80's, perhaps they mapped the mobile variant to the .80 file and the desktop variant to the .40 file. A possibility that could explain what you are seeing. Or, my info regarding .40 for mobile and .80 for desktop was wrong, but if you go looking you should find same info as I did.

I only happen to know a bit about microcode updates in general. It was obvious that it was a packaging error in FreeBSD, because I happen to have a system based on an i5-1235U from the same family and I know that the current firmware version for that family is 0x43a when updated under Linux.

Your applied ucode is a .80, for a 1235U ?

You are correct that Alder Lake R0 is not explicitly listed in the review text itself, only "and others".

However, the proposed fix is directly linked to PR 295351, which is my report, so upstream FreeBSD at least seems to consider it related.

The fix itself is also fairly generic. It changes how ucode-split handles Intel extended signature tables, rather than adding handling for one specific CPU family.

So at this point I think the more important question is probably not whether the visible primary split file is .40 or .80, but whether the relevant signature/platform combination for this CPU is only present in the extended table and therefore currently ignored by ucode-split.

That would also match the observed symptom quite well:

CPU microcode: no matching update found

So I agree it is not fully proven yet that this specifically fixes Alder Lake R0, but the upstream patch and PR linkage make it look very plausible.

I am not with Deciso, in case you missed it.  ;-)

I only happen to know a bit about microcode updates in general. It was obvious that it was a packaging error in FreeBSD, because I happen to have a system based on an i5-1235U from the same family and I know that the current firmware version for that family is 0x43a when updated under Linux.

I guess that @franco will include any current upstream package updates into the next OpnSense releases.
 

thought you're also a MOD and in touch with Franco. As I'm not sure he read this thread :>

Upstream FreeBSD identified the issue and already proposed a fix:

https://reviews.freebsd.org/D57046

The problem was not actually a missing .80 blob specifically, but a bug in ucode-split. Extended signature tables inside Intel microcode blobs were ignored, which caused missing split files for a number of CPUs and therefore:

dmesg:
"CPU microcode: no matching update found"

This affected multiple Intel CPU families, including Alder/Raptor/Arrow Lake and others.

The fix is already linked to the FreeBSD PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

So this does appear to have been a real upstream FreeBSD microcode packaging/splitting issue.

@Franco, meyergru: It would probably be good to pick this up once it lands upstream, since affected OPNsense systems currently appear to stay on older firmware-provided microcode revisions.

Good catch regarding the mobile vs desktop R0 variants. You are right, the i3-1215U is a mobile Alder Lake R0 CPU, so .40 should indeed be the correct platform variant, not .80.

So my original assumption about a missing .80 blob was likely wrong.

However, the interesting part still seems to be:

dmesg:
CPU microcode: no matching update found

combined with:

• installed cpu-microcode-intel package
• stale-looking revision 0x432
• newer revisions apparently existing upstream/Linux side

So there still appears to be some kind of matching/loading issue on this platform, even if the root cause is not the missing .80 variant.

I have opened a FreeBSD bug report for further investigation:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

Hi @Franco,

I may have found a microcode packaging/split-file issue on OPNsense.

System:

Protectli VP6630
Intel Core i3-1215U, Alder Lake R0
coreboot 0.9.0

Installed packages:

Code Select Expand

cpu-microcode-intel-20260227
os-cpu-microcode-intel-1.1
Current microcode after boot:

Code Select Expand

x86info -a | grep -i micro
Microcode version: 0x0000000000000432
Boot message:

Code Select Expand

dmesg | grep -i micro
[1] CPU microcode: no matching update found
The package only provides this split file for CPUID 06-9a-04:

Code Select Expand

/usr/local/share/cpucontrol/06-9a-04.40
but for Intel Core Gen12 / Alder Lake R0 I would expect platform 06-9a-04/80, not /40.

Full relevant output:

Code Select Expand

pkg info -x microcode
cpu-microcode-intel-20260227
os-cpu-microcode-intel-1.1

pkg info -l cpu-microcode-intel | grep -E 'intel-ucode|06-9a-04|microcode'
cpu-microcode-intel-20260227:
        /boot/firmware/intel-ucode.bin
        /usr/local/share/cpucontrol/06-9a-04.40

find /usr/local/share/cpucontrol /boot/firmware -iname '*06-9a-04*' -o -iname '*intel*ucode*'
/usr/local/share/cpucontrol/06-9a-04.40
/boot/firmware/intel-ucode.bin



Is it possible that the split microcode file 06-9a-04.80 is missing from the package, so the Intel microcode plugin cannot update this CPU and keeps the firmware-provided 0x432?

Thanks!


FB

How do you do the Sonos pass on on lan firewall rules?

I just don't. There is no use case for that.

If you need help, I highly recommend to give some insights about your setup.