Created attachment 152816 [details] messages I can reliably reproduce it with rum and wpi (without workaround in wpi_run()). How-to-repeat: ifconfig wlan0 create wlandev rum0 wlanmode ibss && wlandebug debug+input+state && ifconfig wlan0 up && ifconfig wlan0 ssid ssid
Created attachment 152817 [details] backtrace
Is this still a problem?
(In reply to Adrian Chadd from comment #2) Yes, vap->iv_bss is still unitialized. P.S. On my machine (i386, r282543M), (IEEE80211_CHAN_ANYC)->ic_flags dereference does not result in kernel panic - instead, kernel just reads some junk from this address (regression?).
Looks like removing 'vap->iv_flags_ext |= IEEE80211_FEXT_REINIT;' line from ieee80211_proto.c fixes this issue.
ok, that's weird. wonder why it hung around buggy for this long unnoticed. I'm reviewing your scan stuff, so after that yeah, i'll see what removing that line really does everywhere. aiee!
Before https://reviews.freebsd.org/D5145, scanning and <smth> -> INIT (FEXT REINIT) -> <smth2> state transition were two solid parts. How things were worked: 1) network.subr executes 'ifconfig <iface> up', INIT -> SCAN (w/ FEXT_REINIT flag) state transition happens; 2) INIT -> INIT, FEXT_REINIT dropped; 3) INIT -> SCAN, scanning starts (and cannot be interrupted, since newstate_cb() uses the same taskqueue) 4) network.subr executes hostapd / wpa_supplicant -> interface reinitializes. 5) SCAN -> SCAN (w/ FEXT_REINIT flag); the task was enqueued, but (!) will not be executed untill scan ends; 6) scan ends (no networks were seen, so it decides to create another one); SCAN -> RUN state transition is enqueued (FEXT_REINIT is still here, but nstate will be changed to RUN). 7) newstate_cb() is executed, SCAN -> INIT state transition (everything is dropped via ieee80211_reset_bss() call). 8) and INIT -> RUN state transition is issued (with corresponding result). Note: FEXT_REINIT is not added in STA mode, so it's not affected by this bug.
After https://reviews.freebsd.org/D5145 (I remember, that this case does not work, so I have not tested it) scanning is broken into smaller parts; however newstate_cb() was not. As a result: 1), 2) just the same 3) INIT -> SCAN, scanning starts 4) the same 5) SCAN -> SCAN (w/ FEXT_REINIT flag); the task waits untill scan_curchan_task() ends; 6) SCAN -> INIT, FEXT_REINIT is dropped; 7) right here, without waiting untill scan ends, INIT -> SCAN state transition tries to go (but, since F_SCAN flag is set, it hangs here forever).
A commit references this bug: Author: avos Date: Mon Feb 29 21:09:10 UTC 2016 New revision: 296237 URL: https://svnweb.freebsd.org/changeset/base/296237 Log: net80211: fix scanning after D5145 (PR 197498 related) - In case, when we are doing <smth> -> INIT (FEXT_REINIT) -> <smth2> state transition, cancel_scan() may be called in the first transition. Reenqueue second state transition, so things will be executed in order. - Discard any AUTH+ state transition request when INIT -> SCAN transition is not done. - Allow to track discarded state transitions via 'state' debugging category. Tested with: * RTL8188EU, HOSTAP mode. * RTL8188CUS, STA mode. * Intel 3945BG, IBSS and STA modes. PR: 197498 Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5482 Changes: head/sys/net80211/ieee80211_proto.c