1. 13 5月, 2014 1 次提交
  2. 07 5月, 2014 1 次提交
  3. 06 5月, 2014 1 次提交
    • M
      mac80211: fix CSA tx queue stopping · 59af6928
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      59af6928
  4. 25 4月, 2014 2 次提交
  5. 20 3月, 2014 4 次提交
    • E
      cfg80211/mac80211: ignore signal if the frame was heard on wrong channel · 3afc2167
      Emmanuel Grumbach 提交于
      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
      AP.
      
      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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [remove unused rx_freq variable]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3afc2167
    • J
      mac80211: fix suspend vs. authentication race · 1a1cb744
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      1a1cb744
    • J
      mac80211: verify deauthentication and return error on failure · c9c3a060
      Johannes Berg 提交于
      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: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c9c3a060
    • J
      mac80211: fix potential use-after-free · d2722f8b
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      d2722f8b
  6. 28 2月, 2014 1 次提交
  7. 24 2月, 2014 1 次提交
  8. 12 2月, 2014 1 次提交
  9. 11 2月, 2014 2 次提交
  10. 05 2月, 2014 3 次提交
  11. 19 12月, 2013 1 次提交
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      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: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
  12. 16 12月, 2013 1 次提交
    • J
      mac80211: don't delay station destruction · d34ba216
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      d34ba216
  13. 02 12月, 2013 1 次提交
  14. 26 11月, 2013 4 次提交
  15. 25 11月, 2013 1 次提交
  16. 28 10月, 2013 2 次提交
    • C
      mac80211: refactor the parsing of chan switch ie · c0f17eb9
      Chun-Yeow Yeoh 提交于
      Refactor the channel switch IE parsing to reduce the number
      of function parameters.
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c0f17eb9
    • E
      mac80211: implement SMPS for AP · 687da132
      Emmanuel Grumbach 提交于
      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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [fix vht streams loop, initialisation]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      687da132
  17. 17 10月, 2013 1 次提交
    • J
      mac80211: disable WMM with invalid parameters · 095d81ce
      Johannes Berg 提交于
      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: NEliad Peller <eliad@wizery.com>
      Reported-by: NAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      095d81ce
  18. 03 10月, 2013 1 次提交
  19. 26 9月, 2013 2 次提交
  20. 23 8月, 2013 1 次提交
  21. 09 8月, 2013 1 次提交
  22. 01 8月, 2013 4 次提交
  23. 16 7月, 2013 2 次提交
  24. 20 6月, 2013 1 次提交