1. 04 Feb, 2014 1 commit
  2. 19 Dec, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg authored
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  3. 16 Dec, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: don't delay station destruction · d34ba216
      Johannes Berg authored
      If we can assume that stations are never referenced by the
      driver after sta_state returns (and this is true since the
      previous iwlmvm patch and for all other drivers) then we
      don't need to delay station destruction, and don't need to
      play tricks with rcu_barrier() etc.
      This should speed up some scenarios like hostapd shutdown.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  4. 02 Dec, 2013 1 commit
  5. 25 Nov, 2013 5 commits
  6. 28 Oct, 2013 2 commits
    • Chun-Yeow Yeoh's avatar
      mac80211: refactor the parsing of chan switch ie · c0f17eb9
      Chun-Yeow Yeoh authored
      Refactor the channel switch IE parsing to reduce the number
      of function parameters.
      Signed-off-by: default avatarChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Emmanuel Grumbach's avatar
      mac80211: implement SMPS for AP · 687da132
      Emmanuel Grumbach authored
      When the driver requests to move to STATIC or DYNAMIC SMPS,
      we send an action frame to each associated station and
      reconfigure the channel context / driver.
      Of course, non-MIMO stations are ignored.
      The beacon isn't updated. The association response will
      include the original capabilities. Stations that associate
      while in non-OFF SMPS mode will get an action frame right
      after association to inform them about our current state.
      Note that we wait until the end of the EAPOL. Sending an
      action frame before the EAPOL is finished can be an issue
      for a few clients. Clients aren't likely to send EAPOL
      frames in MIMO anyway.
      When the SMPS configuration gets more permissive (e.g.
      STATIC -> OFF), we don't wake up stations that are asleep
      We remember that they don't know about the change and send
      the action frame when they wake up.
      When the SMPS configuration gets more restrictive (e.g.
      OFF -> STATIC), we set the TIM bit for every sleeping STA.
      uAPSD stations might send MIMO until they poll the action
      frame, but this is for a short period of time.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [fix vht streams loop, initialisation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  7. 17 Oct, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: disable WMM with invalid parameters · 095d81ce
      Johannes Berg authored
      Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending
      invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The
      spec mandates that the value of AIFSN is at least 2, and some cards
      (e.g. Intel with the iwldvm driver) can't transmit when the invalid
      QoS parameters are actually uploaded to the firmware.
      Since there's little chance of being able to guess the values that
      the AP actually meant, disable WMM if such an invalid case is found.
      Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2
      and ECWmin <= ECWmax.
      Reviewed-by: default avatarEliad Peller <eliad@wizery.com>
      Reported-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  8. 02 Oct, 2013 1 commit
  9. 26 Sep, 2013 2 commits
  10. 23 Aug, 2013 1 commit
  11. 09 Aug, 2013 1 commit
  12. 31 Jul, 2013 4 commits
    • Johannes Berg's avatar
      mac80211: continue using disabled channels while connected · ddfe49b4
      Johannes Berg authored
      In case the AP has different regulatory information than we do,
      it can happen that we connect to an AP based on e.g. the world
      roaming regulatory data, and then update our database with the
      AP's country information disables the channel the AP is using.
      If this happens on an HT AP, the bandwidth tracking code will
      hit the WARN_ON() and disconnect. Since that's not very useful,
      ignore the channel-disable flag in bandwidth tracking.
      Cc: stable@vger.kernel.org
      Reported-by: default avatarChris Wright <chrisw@sous-sol.org>
      Tested-by: default avatarChris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: ignore HT primary channel while connected · 5cdaed1e
      Johannes Berg authored
      While we're connected, the AP shouldn't change the primary channel
      in the HT information. We checked this, and dropped the connection
      if it did change it.
      Unfortunately, this is causing problems on some APs, e.g. on the
      Netgear WRT610NL: the beacons seem to always contain a bad channel
      and if we made a connection using a probe response (correct data)
      we drop the connection immediately and can basically not connect
      properly at all.
      Work around this by ignoring the HT primary channel information in
      beacons if we're already connected.
      Also print out more verbose messages in the other situations to
      help diagnose similar bugs quicker in the future.
      Cc: stable@vger.kernel.org [3.10]
      Acked-by: default avatarAndy Isaacson <adi@hexapodia.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: don't wait for TX status forever · cb236d2d
      Johannes Berg authored
      TX status notification can get lost, or the frames could
      get stuck on the queue, so don't wait for the callback
      from the driver forever and instead time out after half
      a second.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Chris Wright's avatar
      mac80211: fix infinite loop in ieee80211_determine_chantype · b56e4b85
      Chris Wright authored
      Commit "3d9646d0 mac80211: fix channel selection bug" introduced a possible
      infinite loop by moving the out target above the chandef_downgrade
      while loop.  When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
      back up to re-run the while loop...indefinitely.  Replace goto with
      break and carry on.  This may not be sufficient to connect to the AP,
      but will at least keep the cpu from livelocking.  Thanks to Derek Atkins
      as an extra pair of debugging eyes.
      Cc: stable@kernel.org
      Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  13. 16 Jul, 2013 2 commits
  14. 19 Jun, 2013 1 commit
  15. 18 Jun, 2013 1 commit
  16. 13 Jun, 2013 1 commit
  17. 12 Jun, 2013 1 commit
  18. 05 Jun, 2013 2 commits
  19. 04 Jun, 2013 2 commits
  20. 24 May, 2013 1 commit
    • Johannes Berg's avatar
      cfg80211/mac80211: use cfg80211 wdev mutex in mac80211 · 8d61ffa5
      Johannes Berg authored
      Using separate locks in cfg80211 and mac80211 has always
      caused issues, for example having to unlock in places in
      mac80211 to call cfg80211, which even needed a framework
      to make cfg80211 calls after some functions returned etc.
      Additionally, I suspect some issues people have reported
      with the cfg80211 state getting confused could be due to
      such issues, when cfg80211 is asking mac80211 to change
      state but mac80211 is in the process of telling cfg80211
      that the state changed (in another way.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  21. 17 May, 2013 1 commit
    • Stanislaw Gruszka's avatar
      mac80211: fix direct probe auth · 6211dd12
      Stanislaw Gruszka authored
      We send direct probe to broadcast address, as some APs do not respond to
      unicast PROBE frames when unassociated. Broadcast frames are not acked,
      so we can not use that for trigger MLME state machine, but we need to
      use old timeout mechanism.
      This fixes authentication timed out like below:
      [ 1024.671974] wlan6: authenticate with 54:e6:fc:98:63:fe
      [ 1024.694125] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
      [ 1024.695450] wlan6: direct probe to 54:e6:fc:98:63:fe (try 2/3)
      [ 1024.700586] wlan6: send auth to 54:e6:fc:98:63:fe (try 3/3)
      [ 1024.701441] wlan6: authentication with 54:e6:fc:98:63:fe timed out
      With fix, we have:
      [ 4524.198978] wlan6: authenticate with 54:e6:fc:98:63:fe
      [ 4524.220692] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
      [ 4524.421784] wlan6: send auth to 54:e6:fc:98:63:fe (try 2/3)
      [ 4524.423272] wlan6: authenticated
      [ 4524.423811] wlan6: associate with 54:e6:fc:98:63:fe (try 1/3)
      [ 4524.427492] wlan6: RX AssocResp from 54:e6:fc:98:63:fe (capab=0x431 status=0 aid=1)
      Cc: stable@vger.kernel.org # 3.9
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  22. 16 May, 2013 5 commits
  23. 22 Apr, 2013 1 commit
  24. 16 Apr, 2013 1 commit
    • Alexander Bondar's avatar
      mac80211: remove warning from ieee80211_beacon_loss · 7a7da6ee
      Alexander Bondar authored
      Currently, mac80211 assumes that connection monitor offload
      for BSS station implies that the device:
      - sends periodic keep alive packets to associated AP
      - monitors missed beacons
      - actively probes the AP in case of missed beacons
      In case of poor connection conditions it expects the function
      ieee80211_connection_loss() to be called by driver. However,
      some devices implement connection monitor offload excluding
      active AP probing.
      To allow them to call ieee80211_beacon_loss() cleanly, remove
      the warning there and thus allow them to use mac80211 for the
      AP probing even if connection monitor offload is supported.
      Signed-off-by: default avatarAlexander Bondar <alexander.bondar@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>