1. 26 Jul, 2019 1 commit
  2. 19 Jun, 2019 1 commit
  3. 11 Oct, 2018 1 commit
  4. 28 Apr, 2017 1 commit
  5. 08 Mar, 2017 1 commit
    • Johannes Berg's avatar
      mac80211: reject/clear user rate mask if not usable · e8e4f528
      Johannes Berg authored
      If the user rate mask results in no (basic) rates being usable,
      clear it. Also, if we're already operating when it's set, reject
      it instead.
      
      Technically, selecting basic rates as the criterion is a bit too
      restrictive, but calculating the usable rates over all stations
      (e.g. in AP mode) is harder, and all stations must support the
      basic rates. Similarly, in client mode, the basic rates will be
      used anyway for control frames.
      
      This fixes the "no supported rates (...) in rate_mask ..." warning
      that occurs on TX when you've selected a rate mask that's not
      compatible with the connection (e.g. an AP that enables only the
      rates 36, 48, 54 and you've selected only 6, 9, 12.)
      Reported-by: default avatarKirtika Ruchandani <kirtika@google.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e8e4f528
  6. 06 Mar, 2017 1 commit
  7. 05 Apr, 2016 1 commit
  8. 17 Jul, 2015 1 commit
  9. 20 Apr, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: lock rate control · 35c347ac
      Johannes Berg authored
      Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
      control aren't properly taking concurrency into account. It's
      likely that the same is true for other rate control algorithms.
      
      In the case of minstrel this manifests itself in crashes when an
      update and other data access are run concurrently, for example
      when the stations change bandwidth or similar. In iwlwifi, this
      can cause firmware crashes.
      
      Since fixing all rate control algorithms will be very difficult,
      just provide locking for invocations. This protects the internal
      data structures the algorithms maintain.
      
      I've manipulated hostapd to test this, by having it change its
      advertised bandwidth roughly ever 150ms. At the same time, I'm
      running a flood ping between the client and the AP, which causes
      this race of update vs. get_rate/status to easily happen on the
      client. With this change, the system survives this test.
      Reported-by: default avatarSven Eckelmann <sven@open-mesh.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      35c347ac
  10. 28 Nov, 2014 2 commits
  11. 23 Jun, 2014 1 commit
  12. 04 Feb, 2014 1 commit
  13. 02 Dec, 2013 1 commit
  14. 19 Oct, 2013 1 commit
  15. 16 Jul, 2013 1 commit
  16. 15 Feb, 2013 1 commit
  17. 26 Nov, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: convert to channel definition struct · 4bf88530
      Johannes Berg authored
      Convert mac80211 (and where necessary, some drivers a
      little bit) to the new channel definition struct.
      
      This will allow extending mac80211 for VHT, which is
      currently restricted to channel contexts since there
      are no drivers using that which makes it easier. As
      I also don't care about VHT for drivers not using the
      channel context API, I won't convert the previous API
      to VHT support.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4bf88530
  18. 17 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: use channel contexts · 55de908a
      Johannes Berg authored
      Instead of operating on a single channel only,
      use the new channel context infrastructure in
      all mac80211 code.
      
      This enables drivers that want to use the new
      channel context infrastructure to use multiple
      channels, while nothing should change for all
      the other drivers that don't support it.
      
      Right now this disables both TX power settings
      and spatial multiplexing powersave. Both need
      to be re-enabled on a channel context basis.
      
      Additionally, when channel contexts are used
      drop the connection when channel switch is
      received rather than trying to handle it. This
      will have to be improved later.
      
      [With fixes from Eliad and Emmanuel incorporated]
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      55de908a
  19. 20 Aug, 2012 1 commit
  20. 10 Apr, 2012 2 commits
  21. 15 Feb, 2012 2 commits
  22. 08 Feb, 2012 1 commit
  23. 06 Feb, 2012 1 commit
  24. 24 Jan, 2012 1 commit
  25. 02 Jun, 2010 1 commit
  26. 03 Mar, 2010 1 commit
    • Sujith's avatar
      mac80211: Fix HT rate control configuration · 4fa00437
      Sujith authored
      Handling HT configuration changes involved setting the channel
      with the new HT parameters and then issuing a rate_update()
      notification to the driver.
      
      This behavior changed after the off-channel changes. Now, the channel
      is not updated with the new HT params in enable_ht() - instead, it
      is now done when the scan work terminates. This results in the driver
      depending on stale information, defaulting to non-HT mode always.
      
      Fix this by passing the new channel type to the driver.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4fa00437
  27. 08 Feb, 2010 1 commit
  28. 01 Feb, 2010 1 commit
  29. 12 Jan, 2010 1 commit
    • Jouni Malinen's avatar
      cfg80211/mac80211: Use more generic bitrate mask for rate control · 37eb0b16
      Jouni Malinen authored
      Extend struct cfg80211_bitrate_mask to actually use a bitfield mask
      instead of just a single fixed or maximum rate index. This change
      itself does not modify the behavior (except for debugfs files), but it
      prepares cfg80211 and mac80211 for a new nl80211 command for setting
      which rates can be used in TX rate control.
      
      Since frames are now going through the rate control algorithm
      unconditionally, the internal IEEE80211_TX_INTFL_RCALGO flag can now
      be removed. The RC implementations can use the rate_idx_mask value to
      optimize their behavior if only a single rate is enabled.
      
      The old max_rate_idx in struct ieee80211_tx_rate_control is maintained
      (but commented as deprecated) for backwards compatibility with existing
      RC implementations. Once these implementations have been updated to
      use the more generic rate_idx_mask, the max_rate_idx value can be
      removed.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      37eb0b16
  30. 18 Nov, 2009 1 commit
  31. 28 Mar, 2009 1 commit
  32. 27 Feb, 2009 1 commit
  33. 31 Oct, 2008 2 commits
  34. 06 Oct, 2008 1 commit
  35. 24 Sep, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: clean up rate control API · 4b7679a5
      Johannes Berg authored
      Long awaited, hard work. This patch totally cleans up the rate control
      API to remove the requirement to include internal headers outside of
      net/mac80211/.
      
      There's one internal use in the PID algorithm left for mesh networking,
      we'll have to figure out a way to clean that one up and decide how to
      do the peer link evaluation, possibly independent of the rate control
      algorithm or via new API.
      
      Additionally, ath9k is left using the cross-inclusion hack for now, we
      will add new API where necessary to make this work properly, but right
      now I'm not expert enough to do it. It's still off better than before.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4b7679a5
  36. 15 Sep, 2008 1 commit