1. 20 8月, 2012 3 次提交
  2. 12 7月, 2012 2 次提交
    • J
      mac80211: redesign scan RX · d48b2968
      Johannes Berg 提交于
      Scan receive is rather inefficient when there are
      multiple virtual interfaces. We iterate all of the
      virtual interfaces and then notify cfg80211 about
      each beacon many times.
      
      Redesign scan RX to happen before everything else.
      Then we can also get rid of IEEE80211_RX_IN_SCAN
      since we don't have to accept frames into the RX
      handlers for scanning or scheduled scanning any
      more. Overall, this simplifies the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d48b2968
    • J
      mac80211: track scheduled scan virtual interface · 5260a5b2
      Johannes Berg 提交于
      Instead of tracking whether or not we're in a
      scheduled scan, track the virtual interface
      (sdata) in an RCU-protected pointer to make it
      usable from RX to check the MAC address.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5260a5b2
  3. 11 7月, 2012 1 次提交
  4. 09 7月, 2012 1 次提交
    • J
      cfg80211: use wdev in mgmt-tx/ROC APIs · 71bbc994
      Johannes Berg 提交于
      The management frame and remain-on-channel APIs will be
      needed in the P2P device abstraction, so move them over
      to the new wdev-based APIs. Userspace can still use both
      the interface index and wdev identifier for them so it's
      backward compatible, but for the P2P Device wdev it will
      be able to use the wdev identifier only.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      71bbc994
  5. 28 6月, 2012 1 次提交
  6. 24 6月, 2012 1 次提交
    • J
      mac80211: clean up debugging · bdcbd8e0
      Johannes Berg 提交于
      There are a few things that make the logging and
      debugging in mac80211 less useful than it should
      be right now:
       * a lot of messages should be pr_info, not pr_debug
       * wholesale use of pr_debug makes it require *both*
         Kconfig and dynamic configuration
       * there are still a lot of ifdefs
       * the style is very inconsistent, sometimes the
         sdata->name is printed in front
      
      Clean up everything, introducing new macros and
      separating out the station MLME debugging into
      a new Kconfig symbol.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bdcbd8e0
  7. 22 6月, 2012 1 次提交
  8. 20 6月, 2012 1 次提交
  9. 19 6月, 2012 1 次提交
  10. 06 6月, 2012 1 次提交
  11. 17 5月, 2012 1 次提交
  12. 16 5月, 2012 1 次提交
  13. 10 5月, 2012 2 次提交
  14. 24 4月, 2012 1 次提交
  15. 18 4月, 2012 1 次提交
  16. 11 4月, 2012 1 次提交
  17. 10 4月, 2012 1 次提交
    • F
      mac80211: optimize aggregation session timeout handling · 12d3952f
      Felix Fietkau 提交于
      Calling mod_timer from the rx/tx hotpath is somewhat expensive, and the
      timeout doesn't need to be so precise.
      
      Switch to a different strategy: Schedule the timer initially, store jiffies
      of all last rx/tx activity which would previously modify the timer, and
      let the timer re-arm itself after checking the last rx/tx timestamp.
      Make the session timers deferrable to avoid causing extra wakeups on systems
      running on battery.
      This visibly reduces CPU load under high network load on small embedded
      systems.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      12d3952f
  18. 14 3月, 2012 3 次提交
    • P
      mac80211: Don't let regulatory make us deaf · 3117bbdb
      Paul Stewart 提交于
      When regulatory information changes our HT behavior (e.g,
      when we get a country code from the AP we have just associated
      with), we should use this information to change the power with
      which we transmit, and what channels we transmit.  Sometimes
      the channel parameters we derive from regulatory information
      contradicts the parameters we used in association.  For example,
      we could have associated specifying HT40, but the regulatory
      rules we apply may forbid HT40 operation.
      
      In the situation above, we should reconfigure ourselves to
      transmit in HT20 only, however it makes no sense for us to
      disable receive in HT40, since if we associated with these
      parameters, the AP has every reason to expect we can and
      will receive packets this way.  The code in mac80211 does
      not have the capability of sending the appropriate action
      frames to signal a change in HT behaviour so the AP has
      no clue we can no longer receive frames encoded this way.
      In some broken AP implementations, this can leave us
      effectively deaf if the AP never retries in lower HT rates.
      
      This change breaks up the channel_type parameter in the
      ieee80211_enable_ht function into a separate receive and
      transmit part.  It honors the channel flags set by regulatory
      in order to configure the rate control algorithm, but uses
      the capability flags to configure the channel on the radio,
      since these were used in association to set the AP's transmit
      rate.
      Signed-off-by: NPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Reviewed-by: NLuis R Rodriguez <mcgrof@frijolero.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3117bbdb
    • J
      mac80211: linearize SKBs as needed for crypto · a8286911
      Johannes Berg 提交于
      Not linearizing every SKB will help actually pass
      non-linear SKBs all the way up when on an encrypted
      connection. For now, linearize TKIP completely as
      it is lower performance and I don't quite grok all
      the details.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a8286911
    • J
      mac80211: move RX WEP weak IV counting · 617bbde8
      Johannes Berg 提交于
      This is better done inside the WEP decrypt
      function where it doesn't have to check all
      the conditions any more since they've been
      tested already.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      617bbde8
  19. 07 3月, 2012 1 次提交
  20. 06 3月, 2012 4 次提交
  21. 28 2月, 2012 1 次提交
  22. 07 2月, 2012 2 次提交
    • J
      mac80211: redesign auth/assoc · 66e67e41
      Johannes Berg 提交于
      This is the second part of the auth/assoc redesign,
      the mac80211 part. This moves the auth/assoc code
      out of the work abstraction and into the MLME, so
      that we don't flip channels all the time etc.
      
      The only downside is that when we are associated,
      we need to drop the association in order to create
      a connection to another AP, but for most drivers
      this is actually desirable and the ability to do
      was never used by any applications. If we want to
      implement resource reservation with FT-OTA, we'd
      probably best do it with explicit R-O-C in wpa_s.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      66e67e41
    • J
      mac80211: remove dummy STA support · 7852e361
      Johannes Berg 提交于
      The dummy STA support was added because I didn't
      want to change the driver API at the time. Now
      that we have state transitions triggering station
      add/remove in the driver, we only call add once a
      station reaches ASSOCIATED, so we can remove the
      dummy station stuff again.
      
      While at it, tighten the RX check and accept only
      port control (EAP) frames from the AP station if
      it's not associated yet -- in other cases there's
      no race.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7852e361
  23. 02 2月, 2012 1 次提交
  24. 31 1月, 2012 1 次提交
  25. 28 1月, 2012 1 次提交
  26. 17 1月, 2012 1 次提交
  27. 05 1月, 2012 1 次提交
  28. 22 12月, 2011 1 次提交
  29. 20 12月, 2011 1 次提交
  30. 16 12月, 2011 1 次提交