System crash while connecting to wifi network

(I'm running 13.2-STABLE and using the iwlwifi driver on a Dell Precision laptop.)

The good news is I managed to make my FreeBSD laptop connect to the eduroam wifi network at work :) Very happy with this.

However, in the process I experienced quite a few system crashes/restarts. At the time of the crash I was simply typing in the shell, but it also very reliably crashed every time I did service netif stop.

After modifying a setting in /etc/wpa_supplicant.conf - I had "eap=TTLS" whereas the correct setting was apparently "eap=PEAP" - I can now run the same command without crashing.

So, granted that my /etc/wpa_supplicant.conf settings weren't perfect, but it still doesn't feel right that the system should crash.

Is there anything I can do to make my FreeBSD installation a bit more resilient so it doesn't fall over next time I need to connect to some unusual wifi network? Or is this strictly speaking a bug, and there is nothing I can do besides not using the wrong settings?

Here is - I think - the relevant part of my /var/run/dmesg.boot log file:

wlan1: link state changed to UP
wlan1: link state changed to DOWN
wlan1: link state changed to UP
wlan1: link state changed to DOWN
wlan1: link state changed to UP
wlan1: link state changed to DOWN

Fatal trap 12: page fault while in kernel mode
cpuid = 10; apic id = 0a
fault virtual address   = 0x440
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80be476d
stack pointer           = 0x28:0xfffffe013ee29870
frame pointer           = 0x28:0xfffffe013ee298f0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 289 (wpa_supplicant)
trap number             = 12
panic: page fault
cpuid = 10
time = 1689775572
KDB: stack backtrace:
#0 0xffffffff80c54185 at kdb_backtrace+0x65
#1 0xffffffff80c07ac2 at vpanic+0x152
#2 0xffffffff80c07963 at panic+0x43
#3 0xffffffff810bfde7 at trap_fatal+0x387
#4 0xffffffff810bfe3f at trap_pfault+0x4f
#5 0xffffffff81096ce8 at calltrap+0x8
#6 0xffffffff80d8f5a3 at ieee80211_node_psq_drain+0xf3
#7 0xffffffff80d836c6 at node_cleanup+0xa6
#8 0xffffffff80d835e5 at node_free+0x25
#9 0xffffffff80d84b72 at ieee80211_sta_join1+0xc2
#10 0xffffffff80d85aaa at ieee80211_sta_join+0x42a
#11 0xffffffff80d79e01 at ieee80211_ioctl_setmlme+0x111
#12 0xffffffff80d779ce at ieee80211_ioctl_set80211+0x5de
#13 0xffffffff80d76541 at ieee80211_ioctl+0x311
#14 0xffffffff80d1f63d at ifioctl+0x98d
#15 0xffffffff80c74cb7 at kern_ioctl+0x257
#16 0xffffffff80c749eb at sys_ioctl+0x12b
#17 0xffffffff810c06dc at amd64_syscall+0x10c
Uptime: 4m6s
Last edited by a moderator:
Tried today on my local university and I'm getting kernel panics exactly when I do

service netif restart

or even

wpa_supplicant -i wlan0 -c/etc/wpa_supplicant.conf

I thought it was my wpa_supplicant.conf so I was googling all class and nothing I'll attach to your bug report also

Oh and I can connect to other wpa networks fine and hotspots
jb1277976 - are you also using the iwlwifi driver?

I triggered another kernel panic recently on 14.0-RELEASE with some other "wrong" settings.
Just wanted to report back to say that about a month ago now my bug was fixed, or at least I can't seem to trigger it any more :)

I'm sure there may well be other bugs lurking in this still relatively new driver, so if you come across any, please do report them if you can!