Messages

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.

Moinsen :)


Hab nun nicht alles durchgelesen, muss gleich zur Arbeit.


Allerdings sind in solchen Fällen meine besten Freunde immer: tcpdump, ping und traceroute.

Ich hatte selbst jahrelang ein double nat szenario mit einer Fritte. Lief anstandslos. Allerdings sollte man bedenken, dass die Fritzbox die netze hinter der Firewall nicht kennt. Also entweder natted oder routed man. Nebenher ist das LAN bei eine standardinstallation kein VLAN, wenn das nicht explizit so eingerichtet wurde. Der Fritzbox sind die VLANs hinter der FW allerdings auch herzlich egal :)

Protectli.... Notfalls eine gute gebrauchte. Ich habe nun die zweite in Folge. Als Vorbereitung für Fibre... In meinem Fall eine 6630.


Ja, mich würde eine virtualisierte FW stören. Sogar sehr. Die Gründe dafür sind vielfältig. Hier einige davon.

SPOF - Single Point of Failure
Fällt der Proxmox-Host aus, fällt gleichzeitig die gesamte Firewall und damit das komplette Netzwerk aus.

Boot-Abhängigkeit
Ohne laufende Firewall kann der Hypervisor evtl. keine Updates, NTP, DNS oder Remotezugriff bekommen. Wartung wird komplizierter.

Fehlkonfiguration kann alles lahmlegen
Fehler in virtuellen Switches, Bridges oder VLANs können die Firewall sofort unerreichbar machen.

Sicherheitsrisiko durch Hypervisor
Wird der Hypervisor kompromittiert, ist auch die Firewall kompromittiert. Die Isolation ist schwächer als bei dedizierter Hardware.

Netzwerk-Komplexität steigt
Virtuelle NICs, Bridges und VLAN-Konfigurationen erhöhen die Fehlersuche und machen das Setup anfälliger.

Ressourcenkonkurrenz
Firewall teilt sich CPU/RAM/IO mit VMs -> unter Last kann Routing, VPN oder IDS/IPS langsamer werden.

Wartung verursacht Downtime
Neustart oder Update des Hypervisors unterbricht automatisch die Verbindungen.

Hallo allerseits,

schönes Thema. Dachte eigentlich auch die halten länger. Bin aber auch erst seit Ende 2023 mit NVMEs dabei.

Mir ist letztens meine System Disk 990 Pro 2TB gestorben. Die war in ~3 Jahren so gut wie unbenutzt... Da auf der Disk nur das OS war. TBW sozusagen fast "neu". Kühlung etc kann ich auch ausschließen. Steckt unter der Heatsink eines Aorus Master X670E. Also ein massiver Kühlblock

Bei meiner OPNsense fiel mir auch auf, dass eigentlich zu viel geschrieben wird. Das habe ich nun auf ein minimum reduziert.
=> RAM disk und logging auf extern

Code Select Expand

date && smartctl -a /dev/nvme0 | grep "Data Units Written" Sat Jun 21 10:37:21 CEST 2025 [b]Data Units Written: 30,577,050 [15.6 TB][/b]
date && smartctl -a /dev/nvme0 | grep "Data Units Written" Sun Mar 15 08:35:05 CET 2026 [b]Data Units Written: 31,413,488 [16.0 TB][/b]
Macht nach Adam Ries: ≈ 1.60 GB pro Tag
Einzige was ich auch noch ausgeknippst habe, war das logging von Suricata. Hatte dazu einen Thread hier aufgemacht und ebenfalls eine Github issue.

Wäre cool, wenn jemand Vergleichwerte beisteuern kann.


Edit: Nebenher heißt das Layer 8 / L8... Nix Iso.. Oder auch Fehler 40, oder halt DAU....
Ref: https://de.wikipedia.org/wiki/Layer_8

@Patrick
Die Aussage "IPv6 ist das Internet und IPv4 nur noch Altlast" klingt zwar schön pointiert, ist technisch aber ein bisschen zu grob mit der Axt formuliert. In der Praxis läuft das Internet nach wie vor überwiegend im Dual-Stack, also parallel über IPv4 und IPv6. Selbst große Anbieter liefern Inhalte fast immer über beide Protokolle aus, weil ein erheblicher Teil der Netze weiterhin nur IPv4 oder nur eingeschränktes IPv6 hat.

Auch die pauschale Aussage zur Performance ist so nicht haltbar. Weder das eine noch das andere Protokoll ist per se schneller. Unterschiede entstehen fast immer durch die Providerarchitektur. Etwa wenn IPv4 über CGNAT oder DS-Lite läuft und deshalb einen Umweg macht. Dann kann IPv6 tatsächlich niedrigere Latenzen haben. In Netzen mit nativen IPv4-Routen sieht das aber oft genauso schnell aus.

Kurz gesagt: IPv6 ist definitiv die Zukunft und man sollte es sinnvollerweise aktiv nutzen, wenn der Provider es sauber liefert. Aber IPv4 als "Legacy, das eigentlich schon vorbei ist" darzustellen, ist aktuell eher Wunschdenken als technische Realität. :p Das sagt mir auch mein WAN Simulator im Lab.

Und ja, ich fand IPv6 schon damals in den Cisco/PA/... Trainings+Certs sch..... ;) Nebenher war 1981 ein großartiges Jahr. Nicht nur wegen IPv4 *g*
*duck und wech*




Zum Thema:
Wenn du prüfen willst, ob es wirklich langsamer geworden ist, ein paar einfache Checks:

=> Ping vergleichen: ping -4 und ping -6 auf denselben Host, Latenz und Paketverlust vergleichen.

=> Traceroute getrennt testen: traceroute -4 / traceroute -6, um unterschiedliche Routingpfade zu sehen.

=> Browser DevTools (Network-Tab): DNS-Zeit, TLS-Handshake, TTFB und Gesamtladezeit vergleichen.

=> curl Timing: curl -4 und curl -6 mit Timing-Output (-w), um Connect- und Transferzeiten zu sehen.

=> tcpdump auf der Firewall: schauen, ob Retransmits, ungewöhnliche Delays oder Path-MTU-Probleme auftreten.

=> Wireshark am Client: TCP-Retransmissions, Handshake-Zeiten und mögliche Paketverluste analysieren.

=> iperf3 im eigenen Netz: Durchsatz zwischen Client und Firewall bzw. zwei Hosts prüfen.

Passt folgendes?

- Routing?
- NAT?
- Firewall Regeln?

Notfalls nen dump machen und ebenfalls in den Firewall logs schauen, ob etwas blocked wird.

Program 'OPNsense_Update_Check'
  status                       OK
  monitoring status            Waiting
  monitoring mode              active
  on reboot                    start
  last exit value              0
  last output                  NO_UPDATE: Current version: 26.1.3
  data collected               Thu, 05 Mar 2026 22:27:06

@iani Das ist keine FW Appliance, sondern in Mini-PC mit zwei NICs. Dazu auch noch mit nem Realtek Chipset. Leider ist es bei den meisten dieser Geräte so, dass man keine Ersatzteile bekommt.
In meinem Fall für den Mini-PC auf den mein Home Assistant läuft, durfte ich einen Ersatzlüfter aus China bestellen. Kostenpunkt mit Shipping 42,xx€

Ich hätte Dir auch noch ne FW4B für ~100€ anbieten können. Liegt bei mir nur noch rum.

Living and Learning. Oder Learning by Burning :D

Viel Spass && Erfolg

Für das Heimnetz bin ich persönlich auch ein Freund von Konsolidierung und Virtualisierung. So wenig Hardware wie möglich, nicht zuletzt wegen des Stromverbrauchs.

Mein gesamtes Heimnetz - Switch, GPON-ONT, WLAN-AP, OPNsense, File Server, mehrere RIPE Atlas Probes, LTE-Modem, USV, Freifunk, Smart Home Controller, Hue Bridge, DECT (bestimmt habe ich etwas vergessen) - habe ich mittlerweile auf 32 Watt gedrückt. Und da ist noch Luft nach unten, die nächste Optimierung ist schon geplant. :)

Aber ich stimme Patrick zu, dass man nicht zu viel auf einmal anfangen sollte. Gerade die Konstellation "keine Erfahrung mit OPNsense und keine Erfahrung mit Virtualisierung" sorgt bei vielen schnell für Frust.

Grüße
Maurice

Was die Effizent angeht, gebe ich Dir sicherlich recht.

Trotzdem sollte man meiner Meinung nach gerade bei einer Firewall dem KISS Prinzip folgen. Eine FW ist eine FW und sollte das auch bleiben, ohne jeglichen Overhead.

Meine 2 Cent ...

Lenovo m720q (i5-8500T, 32 GB RAM, SATA- und NVMe SSD) mit PCIe riser und Intel i350-T4 (https://ibb.co/TLdBRXw). OPNsense läuft virtualisiert unter Proxmox. Die Hardware taugt dann auch noch für weiter Spielereien mit PVE. Bezogen von AMSO bzw. dessen Shop bei eBay. Leider nicht mehr so günstig wie vor 2 Jahren.

Willst du, dass bei jeder Wartung an deinem Hypervisor das gesamte Internet weg ist? Das der Hypervisor braucht, um seine Updates (z.B.) herunterzuladen.

Bin mir gerade nicht sicher wobei das Internet öfter "weg" ist. Bei der Wartung von PVE oder bei Updates/Upgrades von OPNsense?

Wenn man kostenbewusst unterwegs ist, wird man sich dieses Teil sicherlich nicht kaufen...


Verlustleistung (TDP) 35 W
Konfigurierbare TDP-down 25 W
14nm...^

eher nicht...