Messages

Ah, January is here, time for opnsense update :-)

No issues so far with the update to 25.1r1; not even the strange german PPPoE stuff produced issues.
Good job team; seemless as it should be ;-)

I also installed it without problems but I'm not sure I understand how the plugin works exactly. Is it a one-time installation or does it keep installing microcode updates in the future?

Also, is there a way to find out if there was actually something installed? As far as I can tell, there's a single plugin for all intel CPUs, how do I know if it applies to my specific model?

The Plug-In installs basically the FreeBSD microcode package (specific for intel or AMD CPUs) and setup some config.
Therefore, with every reboot the update will be applied if for the used CPU there is an update included.

You can check if there was an update applied if you connect via SSH and run the dmesg command.
Quite early in the output there is a line saying "Microcode was updated from x to y".

And no, there is no further maintenance etc. needed, because if there is a newer microcode package merged from FreeBSD base, you will get it with the next opnsense update.
After that, automatically the next reboot use a maybe included newer microcode.

And btw.: as long you want to use the newer microcode, you need to have the plugin installed.
As usual, this microcode plugin is only able to update the CPU on runtime, so no permanent update within the CPU is happening (only a BIOS update can do that)

I used the microcode-package before the official plugin, no problems so far with both options.

CPU: Intel N100

Thanks a lot testing my strange "behavior".
I removed the patch again and after a reboot, the additional gateway disappeared.

Maybe it is a side effect of having multiple patches active at the same time; I removed them now all:

Code Select Expand

287c13beb8e interfaces: avoid touching SLAAC address for now
9ddd363bdbb firmware: add upgrade hint to 24.7 crossing ABI
3a9f98843b0 interfaces: move IPv6 connectivity to a separate s

I also activated the patch and everything is working without an issue.

IPv4: PPPoE
IPv6: DHCPv6 (with "Use IPv4 connectivity" active)

But I saw there something strange:
It seems that after applying the patch, an additional Gateway appeared.
Background:
To access my DSL modem I configured the interface of the PPPoE connection additionally with a static IP (see attachments).

I'm not 100% sure this appeared with the patch, but I can not remember seeing this interface before applying the patch, therefore I assume the patch is the source of it.

Hello,

after upgrading to 24.7 something strange is happening with my TrueNAS environment:

Code Select Expand

Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for fd33:bcd:30fc:9e4b:be24:11ff:feef:9582 on enp6s18.*.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for fe80::be24:11ff:feef:9582 on enp6s18.*.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Withdrawing address record for 2003:ef:bf13:a200:be24:11ff:feef:9582 on enp6s18.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Withdrawing address record for fe80::be24:11ff:feef:9582 on enp6s18.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Withdrawing address record for 10.0.0.4 on enp6s18.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Host name conflict, retrying with erebos-2
Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for fd33:bcd:30fc:9e4b:be24:11ff:feef:9582 on enp6s18.*.
Jul 18 19:30:48 erebos avahi-daemon[4206]: Registering new address record for 10.0.0.4 on enp6s18.IPv4.
Jul 18 19:30:49 erebos avahi-daemon[4206]: Server startup complete. Host name is erebos-2.local. Local service cookie is 1161687643.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/SMB.service) successfully established.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/HTTP.service) successfully established.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/DEV_INFO.service) successfully established.
Jul 18 19:30:50 erebos avahi-daemon[4206]: Service "erebos-2" (/services/ADISK.service) successfully established.

Avahi is the implementation of the Apple Bonjour protocol or MDNS stuff; widely used by systems within the BSD & Linux ecosystem to allow e.g. SMB shares to be discovered by Apple devices.
This messages appeared when I restarted the opnsense the last time; a reboot of the TrueNAS is fixing the issue for the Mac devices because the correct name is online again.

I checked my logs of the TrueNAS system and it started to produce this messages at nearly every restart of the opnsense after when I upgraded to 24.7; that's why I'm asking here and not in the TrueNAS community...

To my setup:
My TrueNAS get a IPv4 address via a static lease from ISC DHCP, IPv6 is configured by "Track interface" on the LAN side and DHCPv6 on the WAN side (PPPoE connection to Telekom Germany).

From my perspective there is something strange going on in 24.7 regarding IPv6, as I also noticed after a reboot that the IPv6 address on the WAN side is active for a second before disappearing for XYZ minutes.
Also the opnsense is not able to get the gateway for IPv6; but the clients get a IPv6 address and are able to use it.

If you need some logs from the opnsense, just say it and I will provide it.

Thanks a lot,
Alex

Sorry that I was not able to test the kernels today, but now I'm back with kernel 24.7.r1_7...
No panic after reboot; let's see how it is performing.

Regarding the NIC topic:
I'm running on a Intel N100 with Intel I226 NICs.

The new kernel is working for me without any issue.
Thanks all for the testing and debugging this problem!

Let's just try this one:

# opnsense-update -zkr 24.7.r1_2

I placed a bet...


Cheers,
Franco

Just installed it, until now no problems or panic.

> Until now no panic with the beta kernel...

Good, here is the next one:

# opnsense-update -zkr 24.7.b_15


Cheers,
Franco

So far no panic after reboot:

Code Select Expand

FreeBSD OPNsense.localdomain 14.1-RELEASE-p1 FreeBSD 14.1-RELEASE-p1 n267732-007d9fa5c015 SMP amd64

Can we keep this thread to the core of the subject?

Let's bisect this then if BETA is good. I'll have a new kernel in a bit.


Cheers,
Franco

Until now no panic with the beta kernel...

We were wondering if this does this also crash with the beta kernel? Because it sort of indicates that it didn't before.

# opnsense-update -kr 24.7.b


Cheers,
Franco

Let's try it out ;-)
Already downloaded, reboot is happening in a sec.

I'm now running the following kernel:

Code Select Expand


FreeBSD OPNsense.localdomain 14.1-RELEASE FreeBSD 14.1-RELEASE stable/24.7-n267717-cf61c67cb34 SMP amd64


I will keep you updated, but directly after the reboot no panic happen.

We were wondering if this does this also crash with the beta kernel? Because it sort of indicates that it didn't before.

# opnsense-update -kr 24.7.b


Cheers,
Franco

Let's try it out ;-)
Already downloaded, reboot is happening in a sec.

Thanks Franco for the update and reaching out to FreeBSD.
It is correct that there is no way to disable pfsync completely? (I checked the man-pages and didn't found any tunable etc.)

Hello,

after updating today from 24.1.10 to 24.7.r1 I had some Kernel panics:

Code Select Expand

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address = 0x20
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80c1dfd0
stack pointer         = 0x28:0xffffffff82841df0
frame pointer         = 0x28:0xffffffff82841e00
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 7 (pf purge)
rdi: 0000000000000000 rsi: 0000000000000000 rdx: fffff80001d15740
rcx: fffff80001d15740  r8: 0000000000003000  r9: 000000000000000f
rax: 0000000000000000 rbx: 0000000000000000 rbp: ffffffff82841e00
r10: fffff801f0ef8000 r11: 000000008083bf61 r12: 0000000000000000
r13: fffff80001d15740 r14: 0000000000000000 r15: 000000000001432c
trap number = 12
panic: page fault
cpuid = 3
time = 1721152911
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82841ae0
vpanic() at vpanic+0x131/frame 0xffffffff82841c10
panic() at panic+0x43/frame 0xffffffff82841c70
trap_fatal() at trap_fatal+0x40b/frame 0xffffffff82841cd0
trap_pfault() at trap_pfault+0x46/frame 0xffffffff82841d20
calltrap() at calltrap+0x8/frame 0xffffffff82841d20
--- trap 0xc, rip = 0xffffffff80c1dfd0, rsp = 0xffffffff82841df0, rbp = 0xffffffff82841e00 ---
turnstile_broadcast() at turnstile_broadcast+0x40/frame 0xffffffff82841e00
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x73/frame 0xffffffff82841e30
pf_unlink_state() at pf_unlink_state+0x338/frame 0xffffffff82841e70
pf_purge_expired_states() at pf_purge_expired_states+0x178/frame 0xffffffff82841ec0
pf_purge_thread() at pf_purge_thread+0x13b/frame 0xffffffff82841ef0
fork_exit() at fork_exit+0x7f/frame 0xffffffff82841f30
fork_trampoline() at fork_trampoline+0xe/frame 0xffffffff82841f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

My first experience was that it is only happening directly after a reboot, but now after some hours without any issue, it happen without any interaction from my side.

I will try to disable some tunables from 24.1 which are currently not required, as e.g. the Microcode upgrade is still active (and it seems like the boot process try to update it...):

Code Select Expand

CPU microcode: updated from 0xe to 0x17
CPU: Intel(R) N100 (806.40-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0xb06e0  Family=0x6  Model=0xbe  Stepping=0


I reported the last two panics via the issue reporter; hopefully this is helping finding the issue.

Thanks,
Alex