When supplying wpa_supplicant.conf with incorrect passwords, but a valid SSID,
I have seen kernel panics several times when using USB based WLAN dongles.
When only supplying a valid password, no panic has been seen.
How to reproduce:
1) configure invalid password
2) wpa_cli: reconfigure
3) configure valid password
4) wpa_cli: reconfigure
5) goto 1
The USB commands which are executed inside the newstate callback usually take
very little time, but still not as little time as PCI read/writes. I've forced
slower operation in the newstate callback, and can reproduce warning printouts
from the IEEE802.11 layer in FreeBSD. Try to apply the following patch to your
In my opinion the deferring of all states to a single task is wrong. There
should be at least one task per possible state, and the queuing mechanism
should follow the last-queued is last executed rule. This is not the case with
the task-queue mechanism in the kernel. See the USB code's task-queue
replacement which I think the IEEE802.11 stack in FreeBSD could take advantage
Description of panics. I didn't have core dump enabled on this box, so please
bear over with the following hand-written notes:
1) A vap->iv_bss == NULL, inside ratectl task in RUM driver.
2) A memcpy() fails inside the iee80211...newstate_cb()
3) This and similar printouts are seen:
wlan0: ieee80211_new_state_locked: pending AUTH -> ASSOC transition lost
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"