1. 05 4月, 2016 1 次提交
    • J
      cfg80211: Allow a scan request for a specific BSSID · 818965d3
      Jouni Malinen 提交于
      This allows scans for a specific BSSID to be optimized by the user space
      application by requesting the driver to set the Probe Request frame
      BSSID field (Address 3) to the specified BSSID instead of the wildcard
      BSSID. This prevents other APs from replying which reduces airtime need
      and latency in getting the response from the target AP through.
      
      This is an optimization and as such, it is acceptable for some of the
      drivers not to support the mechanism. If not supported, the wildcard
      BSSID will be used and more responses may be received.
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      818965d3
  2. 24 2月, 2016 1 次提交
    • L
      cfg80211: basic support for PBSS network type · 34d50519
      Lior David 提交于
      PBSS (Personal Basic Service Set) is a new BSS type for DMG
      networks. It is similar to infrastructure BSS, having an AP-like
      entity called PCP (PBSS Control Point), but it has few differences.
      PBSS support is mandatory for 11ad devices.
      
      Add support for PBSS by introducing a new PBSS flag attribute.
      The PBSS flag is used in the START_AP command to request starting
      a PCP instead of an AP, and in the CONNECT command to request
      connecting to a PCP instead of an AP.
      Signed-off-by: NLior David <liord@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34d50519
  3. 23 2月, 2016 1 次提交
  4. 26 5月, 2015 1 次提交
  5. 07 4月, 2015 1 次提交
  6. 03 3月, 2015 1 次提交
    • D
      cfg80211: add bss_type and privacy arguments in cfg80211_get_bss() · 6eb18137
      Dedy Lansky 提交于
      802.11ad adds new a network type (PBSS) and changes the capability
      field interpretation for the DMG (60G) band.
      The same 2 bits that were interpreted as "ESS" and "IBSS" before are
      re-used as a 2-bit field with 3 valid values (and 1 reserved). Valid
      values are: "IBSS", "PBSS" (new) and "AP".
      
      In order to get the BSS struct for the new PBSS networks, change the
      cfg80211_get_bss() function to take a new enum ieee80211_bss_type
      argument with the valid network types, as "capa_mask" and "capa_val"
      no longer work correctly (the search must be band-aware now.)
      
      The remaining bits in "capa_mask" and "capa_val" are used only for
      privacy matching so replace those two with a privacy enum as well.
      Signed-off-by: NDedy Lansky <dlansky@codeaurora.org>
      [rewrite commit log, tiny fixes]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6eb18137
  7. 10 10月, 2014 1 次提交
  8. 11 9月, 2014 1 次提交
  9. 19 5月, 2014 1 次提交
  10. 05 5月, 2014 1 次提交
    • E
      cfg80211: free sme on connection failures · c1fbb258
      Eliad Peller 提交于
      cfg80211 is notified about connection failures by
      __cfg80211_connect_result() call. However, this
      function currently does not free cfg80211 sme.
      
      This results in hanging connection attempts in some cases
      
      e.g. when mac80211 authentication attempt is denied,
      we have this function call:
      ieee80211_rx_mgmt_auth() -> cfg80211_rx_mlme_mgmt() ->
      cfg80211_process_auth() -> cfg80211_sme_rx_auth() ->
      __cfg80211_connect_result()
      
      but cfg80211_sme_free() is never get called.
      
      Fixes: ceca7b71 ("cfg80211: separate internal SME implementation")
      Cc: stable@vger.kernel.org (3.10+)
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c1fbb258
  11. 29 4月, 2014 1 次提交
  12. 25 4月, 2014 1 次提交
  13. 09 4月, 2014 1 次提交
  14. 20 3月, 2014 1 次提交
  15. 06 2月, 2014 1 次提交
    • J
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg 提交于
      Due to the previous commit, when a scan finishes, it is in theory
      possible to hit the following sequence:
       1. interface starts being removed
       2. scan is cancelled by driver and cfg80211 is notified
       3. scan done work is scheduled
       4. interface is removed completely, rdev->scan_req is freed,
          event sent to userspace but scan done work remains pending
       5. new scan is requested on another virtual interface
       6. scan done work runs, freeing the still-running scan
      
      To fix this situation, hang on to the scan done message and block
      new scans while that is the case, and only send the message from
      the work function, regardless of whether the scan_req is already
      freed from interface removal. This makes step 5 above impossible
      and changes step 6 to be
       5. scan done work runs, sending the scan done message
      
      As this can't work for wext, so we send the message immediately,
      but this shouldn't be an issue since we still return -EBUSY.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9d15d16
  16. 09 1月, 2014 1 次提交
  17. 19 12月, 2013 1 次提交
  18. 05 12月, 2013 1 次提交
    • U
      cfg80211: fix WARN_ON for re-association to the expired BSS · 4c4d684a
      Ujjal Roy 提交于
      cfg80211 allows re-association in managed mode and if a user
      wants to re-associate to the same AP network after the time
      period of IEEE80211_SCAN_RESULT_EXPIRE, cfg80211 warns with
      the following message on receiving the connect result event.
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 13984 at net/wireless/sme.c:658
               __cfg80211_connect_result+0x3a6/0x3e0 [cfg80211]()
      Call Trace:
       [<ffffffff81747a41>] dump_stack+0x46/0x58
       [<ffffffff81045847>] warn_slowpath_common+0x87/0xb0
       [<ffffffff81045885>] warn_slowpath_null+0x15/0x20
       [<ffffffffa05345f6>] __cfg80211_connect_result+0x3a6/0x3e0 [cfg80211]
       [<ffffffff8107168b>] ? update_rq_clock+0x2b/0x50
       [<ffffffff81078c01>] ? update_curr+0x1/0x160
       [<ffffffffa05133d2>] cfg80211_process_wdev_events+0xb2/0x1c0 [cfg80211]
       [<ffffffff81079303>] ? pick_next_task_fair+0x63/0x170
       [<ffffffffa0513518>] cfg80211_process_rdev_events+0x38/0x90 [cfg80211]
       [<ffffffffa050f03d>] cfg80211_event_work+0x1d/0x30 [cfg80211]
       [<ffffffff8105f21f>] process_one_work+0x17f/0x420
       [<ffffffff8105f90a>] worker_thread+0x11a/0x370
       [<ffffffff8105f7f0>] ? rescuer_thread+0x2f0/0x2f0
       [<ffffffff8106638b>] kthread+0xbb/0xc0
       [<ffffffff810662d0>] ? kthread_create_on_node+0x120/0x120
       [<ffffffff817574bc>] ret_from_fork+0x7c/0xb0
       [<ffffffff810662d0>] ? kthread_create_on_node+0x120/0x120
      ---[ end trace 61f3bddc9c4981f7 ]---
      
      The reason is that, in connect result event cfg80211 unholds
      the BSS to which the device is associated (and was held so
      far). So, for the event with status successful, when cfg80211
      wants to get that BSS from the device's BSS list it gets a
      NULL BSS because the BSS has been expired and unheld already.
      
      Fix it by reshuffling the code.
      Signed-off-by: NUjjal Roy <royujjal@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4c4d684a
  19. 09 10月, 2013 1 次提交
  20. 14 8月, 2013 1 次提交
    • J
      cfg80211: don't request disconnect if not connected · dee8a973
      Johannes Berg 提交于
      Neil Brown reports that with libertas, my recent cfg80211
      SME changes in commit ceca7b71
      ("cfg80211: separate internal SME implementation") broke
      libertas suspend because it we now asked it to disconnect
      while already disconnected.
      
      The problematic change is in cfg80211_disconnect() as it
      previously checked the SME state and now calls the driver
      disconnect operation unconditionally.
      
      Fix this by checking if there's a current_bss indicating
      a connection, and do nothing if not.
      Reported-and-tested-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      dee8a973
  21. 16 7月, 2013 1 次提交
    • J
      cfg80211: fix bugs in new SME implementation · 923a0e7d
      Johannes Berg 提交于
      When splitting the SME implementation from the MLME code,
      I introduced a few bugs:
       * association failures no longer sent a connect-failure event
       * getting disassociated from the AP caused deauth to be sent
         but state wasn't cleaned up, leading to warnings
       * authentication failures weren't cleaned up properly, causing
         new connection attempts to warn and fail
      
      Fix these bugs.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      923a0e7d
  22. 24 6月, 2013 2 次提交
  23. 20 6月, 2013 1 次提交
  24. 04 6月, 2013 1 次提交
    • J
      cfg80211: separate internal SME implementation · ceca7b71
      Johannes Berg 提交于
      The current internal SME implementation in cfg80211 is
      very mixed up with the MLME handling, which has been
      causing issues for a long time. There are three things
      that the implementation has to provide:
       * a basic SME implementation for nl80211's connect()
         call (for drivers implementing auth/assoc, which is
         really just mac80211) and wireless extensions
       * MLME events for the userspace SME
       * SME events (connected, disconnected etc.) for all
         different SME implementation possibilities (driver,
         cfg80211 and userspace)
      
      To achieve these goals it isn't necessary to track the
      software SME's connection status outside of it's state
      (which is the part that caused many issues.) Instead,
      track it only in the SME data (wdev->conn) and in the
      general case only track whether the wdev is connected
      or not (via wdev->current_bss.)
      
      Also separate the internal implementation to not have
      callbacks from the SME events, but rather call it from
      the API functions that the driver (or rather mac80211)
      calls. This separates the code better.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ceca7b71
  25. 25 5月, 2013 3 次提交
  26. 24 5月, 2013 1 次提交
  27. 17 5月, 2013 1 次提交
  28. 31 3月, 2013 1 次提交
    • A
      cfg80211: sched_scan_mtx lock in cfg80211_conn_work() · 90e0970f
      Artem Savkov 提交于
      Introduced in f9f47529
      ("cfg80211: always check for scan end on P2P device")
      
      cfg80211_conn_scan() which requires sched_scan_mtx to be held can be called
      from cfg80211_conn_work(). Without this we are hitting multiple warnings like
      the following:
      
      WARNING: at net/wireless/sme.c:88 cfg80211_conn_scan+0x1dc/0x3a0 [cfg80211]()
      Hardware name: 0578A21
      Modules linked in: ...
      Pid: 620, comm: kworker/3:1 Not tainted 3.9.0-rc4-next-20130328+ #326
      Call Trace:
       [<c1036992>] warn_slowpath_common+0x72/0xa0
       [<c10369e2>] warn_slowpath_null+0x22/0x30
       [<faa4b0ec>] cfg80211_conn_scan+0x1dc/0x3a0 [cfg80211]
       [<faa4b344>] cfg80211_conn_do_work+0x94/0x380 [cfg80211]
       [<faa4c3b2>] cfg80211_conn_work+0xa2/0x130 [cfg80211]
       [<c1051858>] process_one_work+0x198/0x450
      Signed-off-by: NArtem Savkov <artem.savkov@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      90e0970f
  29. 24 3月, 2013 1 次提交
    • J
      cfg80211: always check for scan end on P2P device · f9f47529
      Johannes Berg 提交于
      If a P2P device wdev is removed while it has a scan, then the
      scan completion might crash later as it is already freed by
      that time. To avoid the crash always check the scan completion
      when the P2P device is being removed for some reason. If the
      driver already canceled it, don't want and free it, otherwise
      warn and leak it to avoid later crashes.
      
      In order to do this, locking needs to be changed away from the
      rdev mutex (which can't always be guaranteed). For now, use
      the sched_scan_mtx instead, I'll rename it to just scan_mtx in
      a later patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9f47529
  30. 20 3月, 2013 1 次提交
  31. 06 3月, 2013 2 次提交
  32. 12 2月, 2013 1 次提交
  33. 17 1月, 2013 1 次提交
  34. 03 1月, 2013 1 次提交
  35. 30 11月, 2012 1 次提交
    • J
      cfg80211: fix BSS struct IE access races · 9caf0364
      Johannes Berg 提交于
      When a BSS struct is updated, the IEs are currently
      overwritten or freed. This can lead to races if some
      other CPU is accessing the BSS struct and using the
      IEs concurrently.
      
      Fix this by always allocating the IEs in a new struct
      that holds the data and length and protecting access
      to this new struct with RCU.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9caf0364
  36. 18 10月, 2012 1 次提交