Messages

Another Quick update....

Following feedback from the FreeBSD maintainer, I tested late/runtime microcode loading again, including after downgrading to the older cpu-microcode-intel-20260512 package.

After rebooting, the CPU was back at 0x432. The runtime update then successfully applied 0x43b:

/usr/local/share/cpucontrol/06-9a-04.80: updating cpu /dev/cpuctl0 from rev 0x432 to rev 0x43b... done.

This confirms that runtime loading works even with the older package. The remaining issue appears to be specific to the FreeBSD early loader path rather than the microcode package itself.

The FreeBSD bug report has been updated accordingly.

Hallo Christian,

dein Netzwerk sieht auf jeden Fall interessant aus und man merkt, dass du dir viele Gedanken gemacht hast.

Was mich allerdings etwas wundert, ist der Umfang des Projekts. Nach meinem Verständnis muss eine IHK-Abschlussarbeit einen klar abgegrenzten Projektumfang haben, der vor Beginn durch den Prüfungsausschuss genehmigt wird. Erst danach darf das eigentliche Projekt durchgeführt werden.

Je nach IHK liegt die Projektzeit bei etwa 40 Stunden. In dieser Zeit müssen Planung, Umsetzung, Tests sowie die Projektdokumentation erfolgen. Bewertet wird dabei nicht die gesamte vorhandene Infrastruktur, sondern ausschließlich der genehmigte Projektumfang.

Wenn ich deinen Beitrag lese, erkenne ich unter anderem folgende Themen:

- Einführung von IPv6
- Aufbau eines OPNsense-Firewallclusters mit CARP
- mehrere VLANs
- OpenWRT
- KEA-DHCP
- mDNS über VLAN-Grenzen
- Druckdienste
- Routing zwischen mehreren Netzen

Das wirkt auf mich eher wie eine komplette Netzwerkinfrastruktur als wie ein einzelnes IHK-Abschlussprojekt.

Daher hätte ich eine ehrliche Verständnisfrage:

Wäre es möglich, deinen Projektantrag (selbstverständlich anonymisiert) hier zu zeigen? Mich würde interessieren,

- wie das Projektziel formuliert wurde,
- welche Aufgaben tatsächlich Bestandteil des genehmigten Projekts sind,
- wie die Zeitplanung aussieht und
- welcher betriebliche bzw. kundenseitige Nutzen beschrieben wurde.

Ich glaube, das würde auch vielen anderen helfen, den Projektumfang besser einzuordnen.

Zur Orientierung findest du hier die allgemeinen Informationen der IHK zur Projektarbeit und zum Projektantrag:

https://www.ihk.de/blueprint/servlet/resource/blob/6957958/fd54ae065bc407cd8fc092c654af9a96/leitfaden-fi-systemintegration-data.pdf

sowie beispielhafte Hinweise zum Projektantrag und zur Zeitplanung:

https://www.ihk.de/darmstadt/produktmarken/pruefungen/downloads/muther/it-hinweise-projektantrag-2551070

Mich würde wirklich interessieren, wie der Prüfungsausschuss dieses Projekt genehmigt hat, denn nach meiner Erfahrung wäre ein solcher Umfang für eine IHK-Abschlussarbeit eher sehr ungewöhnlich.

Viele Grüße

fb

Ich stehe hier gerade ein wenig auf dem Schlauch?!?

Es ist wirklich so, dass wenn die Sense nicht auf dem aktuellsten Stand ist, dass man keine Plugins installiert bekommt?! Vermutlich hatte ich diesen Status noch nicht, wirkt aber trotzdem ein wenig suspekt?

@kbthomelab88


I guess you did not implement at all what I've described.

Look at your LAN rules. You use as source the SonosNetwork? Why? These rules are useless.

i have upload the picture

We're still waiting for the picture. At the moment I am troubleshooting an non existing attachment rather than your network.

This my lan setup for sonos

Cool Design, how did you manage L2? Looks you do L2 Filtering was well?
Also your micro segmentation look pretty much impressive.

[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.