Als "OpnSense Anfänger" würde mich interessieren, ob meine erste Erfahrung normal ist und ich einfach "da durch" muss, oder ob sie ungewöhnlich ist.
Also:
- gekauft: HUNSN RJ24, Intel Core I3 1215U, AES-NI, 6 x Intel 2.5GbE I226-V, HDMI, DP, USB3.2, Type-C, TF, 16G RAM, 128G SSD
- eigentlich wollte ich erst Proxmox und darunter OpnSense, und anderes. Aber zum "Spielen" erstmal bare metal installiert...
- also opnsense installiert und firmware aktualisiert: version 23.7.8_1
- aktuell (wegen Test und zu Lernen) hinter anderem Router. (Später: router in den bridge-mode, kein doppel NAT)
- Wizard durchlaufen, WAN, LAN, + 1 weiteres interface anlegt. Standard DNS, Auto rules in firewall, keine Routen.
Schaue ich in die Logs (default log levels), sehe ich jede Menge Fehler. Unbound und Web UI crashes. Mehrfach täglich. Also jedesmal per SSH das Web UI neu starten. Dann über UI auch Unbound. Temperatur vor crashes bei 35 °C (IR Thermometer). Nach crash bei 65°C. Nach Neustart der beiden Prozesse geht temp allmählich wieder auf 35°C. Bis zum nächsten Crash. Und ja: erst der Crash, dann steigt langsam die temp.
Dann schlauen Tip zu bestimmten log-Einträgen irgendwo gefunden: CPU opcode aktualisieren. Ok, gemacht. Und tatsächlich: Web UI crasht nicht mehr. Super. Unbound aber weiterhin.
Was für ein Gefrickel! Und ich hab noch nicht mal mit der eigentlichen Konfiguration der Firewall begonnen. Aber wozu auch: das Grundlage ist ja nicht mal stabil. Hatte eigentlich erwartet, dass, selbst wenn ich irgendeinen Mist im UI konfiguriert hätte, doch trotzdem die core prozesse nicht abschmieren.
Ich frag jetzt nicht: was ist das Problem und was die Lösung, denn ich möchte niemandem die Analyse und Lösungsfindung zumuten. Noch dazu ohne wirkliche Details. Und ich fasse mir auch gern an die eigene Nase: Warum hab ich keine "out of the box" firewall gekauft?
Aber ich würde gern wissen: hey, ist das normal zu Beginn?
Das ist nicht meine Erfahrung. Ich lasse die OPNsense ebenfalls auf einer HUNSN Hardware (Intel(R) Core(TM) i5-8265U, 6x Intel I210, 16 GB RAM, 80 GB SSD) von Proxmox 8 virtualisiert laufen und ich habe/hatte nie solche Probleme.
Ich hatte ebenfalls noch nie solche Probleme, weder auf Blech noch in VM.
Einziges Problem was ich jemals mit OPNsense hatte war eine defekte mSATA SSD, wodurch die Installation schon schleppend lief.
Ansonsten ist meine Erfahrung: Installation und schon bertriebsbereit.
Doch, diese Probleme sind bei Alder Lake leider sehr real (https://forum.opnsense.org/index.php?topic=36919).
Kurze Antwort an @sfr: Ja, Du hast eine China-Box - weitgehend ohne Support - der neuesten Generation gekauft, bei der Intel leider mit der auch für sie neuen NUMA-Architektur Bugs schon in der CPU hat, die nur per Microcode-Update beseitigt werden können.
Das ist offensichtlich nicht die Schuld von OpnSense und ja, Du hättest das Problem durch Kauf von besser unterstützter Hardware vermeiden können (z.B. Deciso, Protectli). Drawback: höherer Preis bzw. niedrigere Leistung. Es zeigt sich die alte Regel: Du kannst den Kuchen nicht essen und behalten.
@sbellon: Glück gehabt, da Deine CPU schon vor fünf Jahren vorgestellt wurde und bei der die Microcodes bis auf Security-Updates schon etwas "gereift" sind. Dafür ist sie auch nur halb so schnell wie die von @sfr.
@meyergru: Das hat nix mit Glück zu tun, ich hab vor dem Kauf schon in den einschlägigen Foren recherchiert, ob die verbaute Hardware mit Proxmox und OPNsense funktioniert. Und die Tatsache, dass die Hardware nicht bleeding edge ist, erklärt sich auch ganz einfach: sie ist nicht neu sondern schon Jahre im Einsatz. Und für meine Zwecke (Proxmox virtualisiert OPNsense, Pi-hole, Unifi Controller und Proxmox Backup Server) ist sie mehr als ausreichend dimensioniert.
Ich meinte das nur auf Deine Bemerkung "Ich hatte ebenfalls noch nie solche Probleme, weder auf Blech noch in VM." - wie man sieht, kann einem das passieren. Bei den China-Boxen wird eben immer die aktuellste Bananenware verbaut - wer sich da nicht auskennt, kann halt Pech haben. Und oft genug treten die Probleme erst Monate nach dem Launch auf.
Die Bemerkung "Ich hatte ebenfalls noch nie solche Probleme, weder auf Blech noch in VM." kam nicht von mir ...
Entschuldige: "Das ist nicht meine Erfahrung." meinte ich, was im Endeffekt das Gleiche ist. Durch Deinen und tiermutters Beitrag entstand der Eindruck, es gäbe gar kein Problem. Und das tut es im konkreten Fall.
Ich zielte nur auf den Unterschied ab: Je nach "Glück" bei der Hardware kann die Erfahrung sehr unterschiedlich ausfallen. @sfr hat eben "Pech" gehabt - fraglich, ob man das durch Recherche vorab hätte vermeiden können.
Ich will ja nur sagen: Viele Anfänger ärgern sich lautstark über OpnSense, weil es zu kompliziert ist, bzw. weil Ihre Erfahrung damit schlecht ausfällt. Oft genug sind es die mangelnden Kenntnisse der Delinquenten, nicht OpnSense. Ich bin einer der Ersten, die dann dazu auffordern, die Kirche im Dorf zu lassen, wenn wieder jemand lospoltert.
Trotzdem kann die Erfahrung insgesamt schlecht ausfallen - wie in diesem Fall sogar ohne Schuld von OpnSense und ohne eigene Dummheit.
Ok, das ist eine Basis, auf die ich mich uneingeschränkt mit dir einigen kann. :-)
Vielen Dank für die schnellen und zahlreichen Antworten.
Grad gesehen: C States waren auch disabled... strange. Ich auch gleich mal, ob ich auf der Seite von HUNSN irgendwelche BIOS/EFI updates finde. (Das aktuelle ist vom 1 April. Kein Witz.) Vielleicht hilft es ja...
Interessanterweise ist die Verkaufsseite bei A..... für dieses spezielle Produkt inzwischen offline. hmmm...
Also: Danke schön! =8^)
Ich fürchte, das wird nichts bringen. Hast Du dies (https://forum.opnsense.org/index.php?topic=36139.0) schon gemacht? Läuft Dein System jetzt stabil oder nicht?
Falls nein: Versuch es mal. Danach oder falls ja: Bitte finde mal die CPUID heraus und schau, welche Microcode-Version Du aktuell hast. Wir hatten gerade den Fall (https://forum.opnsense.org/index.php?topic=36919.msg180730#msg180730), dass selbst die bei FreeBSD vorhandenen Microcode-Versionen nicht aktuell genug waren - das war aber eine andere CPU aus der selben Generation.
Trotzdem könntest Du die "early loading" Variante mit einer geänderten intel-ucode.bin versuchen, siehe hier (https://forum.opnsense.org/index.php?topic=36919.msg180675#msg180675).
Mein Senf dazu: Falls man keine Lust auf Experimente hat, dann kauft man bei einer zweckbestimmten Appliance wie OPNsense die Hardware passend zur Software. Falls man gerne bastelt darf es gerne auch etwas anderes sein (mache ich auch manchmal), dann sollte man aber seine Erwartungen entsprechend anpassen.
Grüße
Maurice
Microcode ist aktualisiert (auch bei Neustart) und aktuell "42c". Seit der Aktualisierung läuft ja auch das WEBui stabil. (Hatte genau diesen Beitrag im Forum gefunden)
Etwas seltsam die Ausgabe von x86info. Vielleicht weil es die CPU noch nicht kennt? Vermutlich werden die "performance cores" nicht reported...
x86info:
Found 8 identical CPUs
CPU Model: Unknown Model
Processor name string (BIOS programmed): 12th Gen Intel(R) Core(TM) i3-1215U
...
Microcode Version: 0x000000000000042c
...
This system has 1 quad-core processor with hyper-threading running at estimated 2.5 GhZ
-
@Maurice: na klar. Bastele gern. Schon immer. (Als "alter Sack" zuerst am Odner Arithmometer, dann mit ZX81 mit 32KB Speichererweiterung per Klettband am hinteren "port". Jetzt gern ESP-12. Großer Spaß. ). Wollte ja auch nur wissen, ob meine erste Erfahrung mit dem "Nebenprojekt Firewall") komplett daneben ist.
@sfr Ich würde sagen, deine erste Erfahrung ist stark Hardware-spezifisch. Habe vergleichbares in sechs Jahren OPNsense nicht erlebt, verwende dafür aber auch nur gut abgehangene Hardware und zudem Virtualisierung. Mein Ansatz ist, dass OPNsense selbst genug Baustellen hat, da muss ich mich nicht auch noch mit den Problemchen von Bleeding Edge-Hardware herumschlagen. Das dürfen die FreeBSD-Leute machen.
Auf einem ZX81 wird es aber eher nicht laufen. 😁
Viel Erfolg noch!
Quote from: sfr on November 17, 2023, 02:47:10 PM
Etwas seltsam die Ausgabe von x86info. Vielleicht weil es die CPU noch nicht kennt? Vermutlich werden die "performance cores" nicht reported...
Das ist gut möglich, Bekannter von mir hatte das selbe Problem mit einem MiniPC mit ganz aktueller CPU, war aber ein anderer Hersteller als deiner, aber selbe CPU.
Lösung: leider nein, mein Bekannter hatte den MiniPC zurück geschickt und gehen einen andere von Protectli ausgetauscht, der ne ältere CPU hat aber dafür stabil und fehlerfrei läuft.
Das ist aber genau der Punkt, warum es nicht immer sinnvoll ist, die neuste Hardware zu nehmen, dazu hatte ich letztens schon eine Diskussion mit jemanden.
Ich bräuchte den Output von "x86info -a", die Bezeichnung kenne ich, ich will die CPUID. Vorzugsweise auch den Output von dmesg, von welcher Ursprungsversion das Update auf 42c erfolgt.
Und dann sagst Du immer noch nicht klar, ob Du bereits das von mir bereitgestellte intel-ucode.bin verwendest oder nur das normale Microcode-Update (ich schätze letzteres, denn bei Platomav gibt es keine Version 42c.) Ohne CPUID kann ich das aber nicht checken, ob es etwas Neueres gibt.
Die Updates für Alder Lake kamen erst in den letzten paar Wochen, die sind in den Standard-Updates nicht drin...
x86info -a im Anhang.
CPUID ist: Extended Family: 0 Extended Model: 9 Family: 6 Model: 154 Stepping: 4
1. "normales" microcode update eingespielt: 42c
2. Danach Deine ucode.bin gecurled und reboot: 42c
dmesg vergessen .. jetzt im Anhang
Da ist laut dmesg kein Microcode-Update erfolgt. Platomav hat für Deine CPUID 906A4 die Version 430 seit September. Die wird bei Intel auch gelistet (https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases). Meine Vermutung ist, dass die Version 42c bereits im BIOS enthalten ist.
Prüfe bitte, ob die "early load" Einträge in /boot/loader.conf enthalten sind wie hier (https://forum.opnsense.org/index.php?topic=36919.msg180706#msg180706) beschrieben und die intel-ucode.bin am richtigen Platz liegt.
loader.conf:
...
# dynamically generated tunables settings follow
cpu_microcode_load=""YES""
cpu_microcode_name=""/boot/firmware/intel-ucode.bin""
hw.ibrs_disable="0"
...
und:
# cd /boot/firmware
# ls -als
total 26318
1 drwxr-xr-x 2 root wheel 4 Nov 17 15:12 .
9 drwxr-xr-x 15 root wheel 71 Nov 10 15:58 ..
13621 -rw-r--r-- 1 root wheel 14254080 Nov 17 15:12 intel-ucode.bin
12689 -rw-r--r-- 1 root wheel 13120512 Nov 8 02:12 intel-ucode.bin.bak
sieht eigentlich gut aus ... hmm. intel-ucode.bin hatte ich von Dir geholt und auch reboot.
Schau Dir mal die doppelten Quotes in der /boot/loader.conf an... ;-)
F..k
x-mal drübergelesen ... :-(
ok, dann ändere ich das mal ... :-/
dmesg:
CPU microcode: no matching update found
ok, ich schau noch mal in Ruhe ...
Keine Ahnung, wieso es bei Dir nicht gefunden wird. Ich habe es gecheckt und in der Datei ist die richtige Version eigentlich drin:
#iucode-tool -L intel-ucode.bin | fgrep 0906a
sig 0x000906a0, pf_mask 0x82, 2021-06-14, rev 0x001c
001/420: sig 0x000906a1, pf_mask 0x82, 2021-11-04, rev 0x011f, size 184320
001/421: sig 0x000906a2, pf_mask 0x80, 2022-01-02, rev 0x0315, size 206848
001/422: sig 0x000906a3, pf_mask 0x80, 2023-06-07, rev 0x0430, size 220160
sig 0x000906a3, pf_mask 0x80, 2023-06-07, rev 0x0430
sig 0x000906a4, pf_mask 0x80, 2023-06-07, rev 0x0430
001/423: sig 0x000906a4, pf_mask 0xc3, 2022-05-09, rev 0x0002, size 112640
001/424: sig 0x000906a4, pf_mask 0x40, 2023-05-05, rev 0x0005, size 117760
Inzwischen gibt es ein neues FreeBSD-Package mit den Intel-Updates vom 14.11.2023 für Alder Lake. Man kann es updaten mit:
curl -o cpu-microcode-intel-20231114.pkg https://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/cpu-microcode-intel-20231114.pkg
pkg upgrade -y cpu-microcode-intel-20231114.pkg
Ich habe @Franco schon gebeten, das Package ins offizielle OpnSense-Repository aufzunehmen.
Microcode version: 0x0000000000000430
So .... jetzt mal schauen, ob sich eine Verbesserung der Stabilität einstellt.
Vielen lieben Dank! Hatte nicht erwartet, dass mir überhaupt geholfen würde ... Wo finde ich den Knopf für den Kaffee?
Kurze Rückmeldung:
- Keine crashes
- Log files sehr übersichtlich und vollkommen unauffällig
- Temperatur um die 40°C in 24°C Umgebung
In Summe: so soll es wohl sein. Ich werde das noch ein paar Tage beobachten und mich ein wenig einlesen.
Wenn es bis zum nächsten WE weiterhin stabil läuft, mach ich alles platt und setze neu unter Proxmox auf.
Besten Dank!
Dir ist schon klar, dass Du dort das selbe Problem wieder hast? Du kannst nicht aus einer VM heraus den Microcode updaten.
Hatte in meiner Naivität gehofft, dies beim Start von Proxmox zu können und dass dies dann für alle Gast-OS/container ausreicht ...
Nun gut, dann gehe ich nochmal in mich ... Danke für den Hinweis ...
Quote from: sfr on November 18, 2023, 11:55:15 AM
Hatte in meiner Naivität gehofft, dies beim Start von Proxmox zu können und dass dies dann für alle Gast-OS/container ausreicht ...
Nun gut, dann gehe ich nochmal in mich ... Danke für den Hinweis ...
Das kannst Du mit den Linux-Microcode-Paketen.
Nur ist in den aktuellen OS-Distributionen die Version 430 für Deine CPU vermutlich noch genausowenig drin wie für FreeBSD... wobei es dafür ja gerade kommt.