1. 10 11月, 2014 1 次提交
  2. 04 11月, 2014 1 次提交
    • J
      mac80211: handle RIC data element in reassociation request · 8ed28747
      Johannes Berg 提交于
      When the RIC data element (RDE) is included in the IEs coming
      from userspace for an association request, its handling is
      currently broken as any IEs that are contained within it would
      be split off from it and inserted again after all the IEs that
      mac80211 generates (e.g. HT, VHT.)
      
      To fix this, treat the RIC element specially, and stop after
      it only when we find something that doesn't actually belong to
      it. This assumes userspace is actually correctly building it,
      directly after the fast BSS transition IE and before all the
      others like extended capabilities.
      
      This leaves as a potential problem the case where userspace is
      building the following IEs:
      
      [RDE] [vendor resource description] [vendor non-resource IE]
      
      In this case, we'd erroneously consider all three IEs to be
      part of the RIC data together, and not split them between the
      two vendor IEs. Unfortunately, it isn't easily possible to
      distinguish vendor IEs, so this isn't easy to fix. Luckily,
      this case is rare as normally wpa_supplicant will include an
      extended capabilities IE in the IEs, and that certainly will
      break the two vendor IEs apart correctly.
      Reviewed-by: NEliad Peller <eliad@wizery.com>
      Reviewed-by: NBeni Lev <beni.lev@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8ed28747
  3. 27 10月, 2014 1 次提交
  4. 22 10月, 2014 1 次提交
    • J
      mac80211: add WMM admission control support · 02219b3a
      Johannes Berg 提交于
      Use the currently existing APIs between mac80211 and the low
      level driver to implement WMM admission control.
      
      The low level driver needs to report the media time used by
      each transmitted packet in ieee80211_tx_status. Based on that
      information, mac80211 will modify the QoS parameters of the
      admission controlled Access Category when the limit is
      reached. Once the original QoS parameters can be restored,
      mac80211 will do so.
      
      One issue with this approach is that management frames will
      also erroneously be downgraded, but the upside is that the
      implementation is simple. In the future, it can be extended
      to driver- or device-based implementations that are better.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      02219b3a
  5. 09 10月, 2014 5 次提交
  6. 11 9月, 2014 2 次提交
  7. 08 9月, 2014 2 次提交
    • S
      mac80211: support DTPC IE (from Cisco Client eXtensions) · c8d65917
      Steinar H. Gunderson 提交于
      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
      anyway.
      Signed-off-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      c8d65917
    • S
      mac80211: split 802.11h parsing from transmit power policy · 24a4e400
      Steinar H. Gunderson 提交于
      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: NSteinar H. Gunderson <sgunderson@bigfoot.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      24a4e400
  8. 05 9月, 2014 3 次提交
  9. 26 8月, 2014 1 次提交
  10. 15 8月, 2014 2 次提交
  11. 21 7月, 2014 3 次提交
  12. 26 6月, 2014 1 次提交
  13. 23 6月, 2014 2 次提交
  14. 13 5月, 2014 1 次提交
  15. 07 5月, 2014 1 次提交
  16. 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
  17. 25 4月, 2014 2 次提交
  18. 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
  19. 28 2月, 2014 1 次提交
  20. 24 2月, 2014 1 次提交
  21. 12 2月, 2014 1 次提交
  22. 11 2月, 2014 2 次提交
  23. 05 2月, 2014 1 次提交