Bug 197498 - [net80211]: Setting ssid on running interface in adhoc mode causes panic
Summary: [net80211]: Setting ssid on running interface in adhoc mode causes panic
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-09 19:12 UTC by Andriy Voskoboinyk
Modified: 2019-01-17 04:26 UTC (History)
2 users (show)

See Also:


Attachments
messages (4.37 KB, text/plain)
2015-02-09 19:12 UTC, Andriy Voskoboinyk
no flags Details
backtrace (3.35 KB, text/plain)
2015-02-09 19:14 UTC, Andriy Voskoboinyk
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Voskoboinyk freebsd_committer freebsd_triage 2015-02-09 19:12:21 UTC
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
Comment 1 Andriy Voskoboinyk freebsd_committer freebsd_triage 2015-02-09 19:14:02 UTC
Created attachment 152817 [details]
backtrace
Comment 2 Adrian Chadd freebsd_committer freebsd_triage 2015-05-04 00:49:03 UTC
Is this still a problem?
Comment 3 Andriy Voskoboinyk freebsd_committer freebsd_triage 2015-05-08 15:48:28 UTC
(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?).
Comment 4 Andriy Voskoboinyk freebsd_committer freebsd_triage 2016-02-27 22:56:43 UTC
Looks like removing 'vap->iv_flags_ext |= IEEE80211_FEXT_REINIT;' line from ieee80211_proto.c fixes this issue.
Comment 5 Adrian Chadd freebsd_committer freebsd_triage 2016-02-28 08:34:55 UTC
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!
Comment 6 Andriy Voskoboinyk freebsd_committer freebsd_triage 2016-02-28 09:43:48 UTC
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.
Comment 7 Andriy Voskoboinyk freebsd_committer freebsd_triage 2016-02-28 09:52:24 UTC
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).
Comment 8 commit-hook freebsd_committer freebsd_triage 2016-02-29 21:09:57 UTC
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