1. 11 Sep, 2014 2 commits
  2. 08 Sep, 2014 2 commits
    • Steinar H. Gunderson's avatar
      mac80211: support DTPC IE (from Cisco Client eXtensions) · c8d65917
      Steinar H. Gunderson authored
      Linux already supports 802.11h, where the access point can tell the
      client to reduce its transmission power. However, 802.11h is only
      defined for 5 GHz, where the need for this is much smaller than on
      2.4 GHz.
      Cisco has their own solution, called DTPC (Dynamic Transmit Power
      Control). Cisco APs on a controller sometimes but not always send
      802.11h; they always send DTPC, even on 2.4 GHz. This patch adds support
      for parsing and honoring the DTPC IE in addition to the 802.11h
      element (they do not always contain the same limits, so both must
      be honored); the format is not documented, but very simple.
      Tested (on top of wireless.git and on 3.16.1) against a Cisco Aironet
      1142 joined to a Cisco 2504 WLC, by setting various transmit power
      levels for the given access points and observing the results.
      The Wireshark 802.11 dissector agrees with the interpretation of the
      element, except for negative numbers, which seem to never happen
      Signed-off-by: default avatarSteinar H. Gunderson <sgunderson@bigfoot.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
    • Steinar H. Gunderson's avatar
      mac80211: split 802.11h parsing from transmit power policy · 24a4e400
      Steinar H. Gunderson authored
      Decouple the logic of parsing the 802.11d and 802.11h IEs from the
      part of deciding what to do about the data (messaging, clamping to
      0 dBm, doing the actual setting). This paves the way for the next
      patch, which introduces more data sources for transmit power limitation.
      Signed-off-by: default avatarSteinar H. Gunderson <sgunderson@bigfoot.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  3. 05 Sep, 2014 3 commits
  4. 26 Aug, 2014 1 commit
  5. 15 Aug, 2014 2 commits
  6. 21 Jul, 2014 3 commits
  7. 25 Jun, 2014 1 commit
  8. 23 Jun, 2014 2 commits
  9. 13 May, 2014 1 commit
  10. 07 May, 2014 1 commit
  11. 06 May, 2014 1 commit
    • Michal Kazior's avatar
      mac80211: fix CSA tx queue stopping · 59af6928
      Michal Kazior authored
      It was possible for tx queues to be stuck stopped
      if AP CSA finalization failed. In that case
      neither stop_ap nor do_stop woke the queues up.
      This means it was impossible to perform tx at all
      until driver was reloaded or a successful CSA was
      performed later.
      It was possible to solve this in a simpler manner
      however this is more robust and future proof
      (having multi-vif CSA in mind).
      New sdata->csa_block_tx is introduced to keep
      track of which interfaces requested tx to be
      blocked for CSA. This is required because mac80211
      stops all tx queues for that purpose. This means
      queues must be awoken only when last tx-blocking
      CSA interface is finished.
      It is still possible to have tx queues stopped
      after CSA failure but as soon as offending
      interfaces are stopped from userspace (stop_ap or
      ifdown) tx queues are woken up properly.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  12. 25 Apr, 2014 2 commits
  13. 19 Mar, 2014 4 commits
    • Emmanuel Grumbach's avatar
      cfg80211/mac80211: ignore signal if the frame was heard on wrong channel · 3afc2167
      Emmanuel Grumbach authored
      On 2.4Ghz band, the channels overlap since the delta
      between different channels is 5Mhz while the width of the
      receiver is 20Mhz (at least).
      This means that we can hear beacons or probe responses from
      adjacent channels. These frames will have a significant
      lower RSSI which will feed all kinds of logic with inaccurate
      data. An obvious example is the roaming algorithm that will
      think our AP is getting weak and will try to move to another
      In order to avoid this, update the signal only if the frame
      has been heard on the same channel as the one advertised by
      the AP in its DS / HT IEs.
      We refrain from updating the values only if the AP is
      already in the BSS list so that we will still have a valid
      (but inaccurate) value if the AP was heard on an adjacent
      channel only.
      To achieve this, stop taking the channel from DS / HT IEs
      in mac80211. The DS / HT IEs is taken into account to
      discard the frame if it was received on a disabled channel.
      This can happen due to the same phenomenon: the frame is
      sent on channel 12, but heard on channel 11 while channel
      12 can be disabled on certain devices. Since this check
      is done in cfg80211, stop even checking this in mac80211.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [remove unused rx_freq variable]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: fix suspend vs. authentication race · 1a1cb744
      Johannes Berg authored
      Since Stanislaw's patch removing the quiescing code, mac80211 had
      a race regarding suspend vs. authentication: as cfg80211 doesn't
      track authentication attempts, it can't abort them. Therefore the
      attempts may be kept running while suspending, which can lead to
      all kinds of issues, in at least some cases causing an error in
      iwlmvm firmware.
      Fix this by aborting the authentication attempt when suspending.
      Cc: stable@vger.kernel.org
      Fixes: 12e7f517 ("mac80211: cleanup generic suspend/resume procedures")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: verify deauthentication and return error on failure · c9c3a060
      Johannes Berg authored
      When still authenticating the mac80211 code handling a deauthentication
      requests from userspace doesn't verify that the request is valid in any
      way, fix that. Additionally, it never returns an error, even if there's
      no connection or authentication attempt, fix that as well.
      While at it, move the message to not print a message in the error case
      and to distinguish between the two cases.
      Also simplify the code by duplicating the cfg80211 call.
      Reviewed-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: fix potential use-after-free · d2722f8b
      Johannes Berg authored
      The bss struct might be freed in ieee80211_rx_bss_put(),
      so we shouldn't use it afterwards.
      Cc: stable@vger.kernel.org (3.10+)
      Fixes: 817cee76 ("mac80211: track AP's beacon rate and give it to the driver")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  14. 27 Feb, 2014 1 commit
  15. 24 Feb, 2014 1 commit
  16. 12 Feb, 2014 1 commit
  17. 11 Feb, 2014 2 commits
  18. 05 Feb, 2014 1 commit
  19. 04 Feb, 2014 2 commits
  20. 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>
  21. 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>
  22. 02 Dec, 2013 1 commit
  23. 25 Nov, 2013 4 commits