[Bug 197498] [net80211]: Setting ssid on running interface in adhoc mode causes panic

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

Bug ID: 197498
Summary: [net80211]: Setting ssid on running interface in adhoc
mode causes panic
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: wireless
Assignee: freebsd-***@FreeBSD.org
Reporter: ***@gmail.com

Created attachment 152816
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152816&action=edit
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

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

--- Comment #1 from Andriy Voskoboinyk <***@gmail.com> ---
Created attachment 152817
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=152817&action=edit
backtrace

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

Adrian Chadd <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@freebsd.org

--- Comment #2 from Adrian Chadd <***@freebsd.org> ---
Is this still a problem?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

--- Comment #3 from Andriy Voskoboinyk <***@gmail.com> ---
(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?).

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

Andriy Voskoboinyk <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@freebsd.org
Status|New |Open

--- Comment #4 from Andriy Voskoboinyk <***@freebsd.org> ---
Looks like removing 'vap->iv_flags_ext |= IEEE80211_FEXT_REINIT;' line from
ieee80211_proto.c fixes this issue.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

--- Comment #5 from Adrian Chadd <***@freebsd.org> ---
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!

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

Andriy Voskoboinyk <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|Open |In Progress

--- Comment #6 from Andriy Voskoboinyk <***@freebsd.org> ---
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.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

--- Comment #7 from Andriy Voskoboinyk <***@freebsd.org> ---
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).

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

--- Comment #8 from commit-***@freebsd.org ---
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

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

Andriy Voskoboinyk <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|In Progress |Closed

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197498

Andriy Voskoboinyk <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freebsd.org/bu
| |gzilla/show_bug.cgi?id=2086
| |36