1. 17 3月, 2015 1 次提交
  2. 27 1月, 2015 4 次提交
  3. 23 1月, 2015 1 次提交
    • J
      mac80211: allow drivers to control software crypto · fa7e1fbc
      Johannes Berg 提交于
      Some drivers unfortunately cannot support software crypto, but
      mac80211 currently assumes that they do.
      
      This has the issue that if the hardware enabling fails for some
      reason, the software fallback is used, which won't work. This
      clearly isn't desirable, the error should be reported and the
      key setting refused.
      
      Support this in mac80211 by allowing drivers to set a new HW
      flag IEEE80211_HW_SW_CRYPTO_CONTROL, in which case mac80211 will
      only allow software fallback if the set_key() method returns 1.
      The driver will also need to advertise supported cipher suites
      so that mac80211 doesn't advertise any (future) software ciphers
      that the driver can't actually do.
      
      While at it, to make it easier to support this, refactor the
      ieee80211_init_cipher_suites() code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fa7e1fbc
  4. 07 1月, 2015 1 次提交
    • I
      mac80211: Re-fix accounting of the tailroom-needed counter · db12847c
      Ido Yariv 提交于
      When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags
      only require headroom space. Therefore, the tailroom-needed counter can
      safely be decremented for most drivers.
      
      The older incarnation of this patch (ca34e3b5) assumed that the above
      holds true for all drivers. As reported by Christopher Chavez and
      researched by Christian Lamparter and Larry Finger, this isn't a valid
      assumption for p54 and cw1200.
      
      Drivers that still require tailroom for ICV/MIC even when HW encryption
      is enabled can use IEEE80211_KEY_FLAG_RESERVE_TAILROOM to indicate it.
      Signed-off-by: NIdo Yariv <idox.yariv@intel.com>
      Cc: Christopher Chavez <chrischavez@gmx.us>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Solomon Peachy <pizza@shaftnet.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      db12847c
  5. 05 1月, 2015 1 次提交
  6. 17 12月, 2014 1 次提交
  7. 22 10月, 2014 1 次提交
  8. 11 9月, 2014 1 次提交
  9. 05 9月, 2014 1 次提交
  10. 26 8月, 2014 1 次提交
  11. 21 7月, 2014 1 次提交
  12. 29 4月, 2014 1 次提交
    • J
      mac80211: remove BUG_ON usage · 8c5bb1fa
      Johannes Berg 提交于
      These BUG_ON statements should never trigger, but in the unlikely
      event that somebody does manage don't stop everything but simply
      exit the code path with an error.
      
      Leave the one BUG_ON where changing it would result in a NULL
      pointer dereference.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8c5bb1fa
  13. 16 12月, 2013 2 次提交
  14. 26 11月, 2013 2 次提交
  15. 26 9月, 2013 1 次提交
  16. 16 8月, 2013 1 次提交
    • J
      mac80211: add APIs to allow keeping connections after WoWLAN · 27b3eb9c
      Johannes Berg 提交于
      In order to be able to (securely) keep connections alive after
      the system was suspended for WoWLAN, we need some additional
      APIs. We already have API (ieee80211_gtk_rekey_notify) to tell
      wpa_supplicant about the new replay counter if GTK rekeying
      was done by the device while the host was asleep, but that's
      not sufficient.
      
      If GTK rekeying wasn't done, we need to tell the host about
      sequence counters for the GTK (and PTK regardless of rekeying)
      that was used while asleep, add ieee80211_set_key_rx_seq() for
      that.
      
      If GTK rekeying was done, then we need to be able to disable
      the old keys (with ieee80211_remove_key()) and allocate the
      new GTK key(s) in mac80211 (with ieee80211_gtk_rekey_add()).
      
      If protocol offload (e.g. ARP) is implemented, then also the
      TX sequence counter for the PTK must be updated, using the new
      ieee80211_set_key_tx_seq() function.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      27b3eb9c
  17. 17 5月, 2013 1 次提交
  18. 11 3月, 2013 3 次提交
  19. 06 3月, 2013 3 次提交
    • J
      mac80211: defer tailroom counter manipulation when roaming · 8d1f7ecd
      Johannes Berg 提交于
      During roaming, the crypto_tx_tailroom_needed_cnt counter
      will often take values 2,1,0,1,2 because first keys are
      removed and then new keys are added. This is inefficient
      because during the 0->1 transition, synchronize_net must
      be called to avoid packet races, although typically no
      packets would be flowing during that time.
      
      To avoid that, defer the decrement (2->1, 1->0) when keys
      are removed (by half a second). This means the counter
      will really have the values 2,2,2,3,4 ... 2, thus never
      reaching 0 and having to do the 0->1 transition.
      
      Note that this patch entirely disregards the drivers for
      which this optimisation was done to start with, for them
      the key removal itself will be expensive because it has
      to synchronize_net() after the counter is incremented to
      remove the key from HW crypto. For them the sequence will
      look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
      lot more inefficient. This could be addressed separately,
      during key removal the 0->1->0 sequence isn't necessary.
      
      (*) it starts at 0 because HW crypto is on, then goes to
          1 when HW crypto is disabled for a key, then back to
          0 because the key is deleted; this happens for both
          keys in the example. When new keys are added, it goes
          to 1 first because they're added in software; when a
          key is moved to hardware it goes back to 0
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8d1f7ecd
    • J
      mac80211: remove IEEE80211_KEY_FLAG_WMM_STA · a8712105
      Johannes Berg 提交于
      There's no driver using this flag, so it seems
      that all drivers support HW crypto with WMM or
      don't support it at all. Remove the flag and
      code setting it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a8712105
    • S
      mac80211: cleanup generic suspend/resume procedures · 12e7f517
      Stanislaw Gruszka 提交于
      Since now we disconnect before suspend, various code which save
      connection state can now be removed from suspend and resume
      procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
      is also used for H/W restart.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      12e7f517
  20. 18 1月, 2013 1 次提交
  21. 19 11月, 2012 2 次提交
  22. 06 9月, 2012 1 次提交
  23. 09 7月, 2012 1 次提交
  24. 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
  25. 28 2月, 2012 1 次提交
  26. 07 2月, 2012 2 次提交
  27. 09 11月, 2011 1 次提交
  28. 01 11月, 2011 1 次提交
  29. 01 10月, 2011 1 次提交
    • J
      mac80211: optimise station flags · c2c98fde
      Johannes Berg 提交于
      The flaglock in struct sta_info has long been
      something that I wanted to get rid of, this
      finally does the conversion to atomic bitops.
      
      The conversion itself is straight-forward in
      most places, a few things needed to change a
      bit since we can no longer use multiple bits
      at the same time.
      
      On x86-64, this is a fairly significant code
      size reduction:
         text	   data	    bss	    dec	    hex
       427861	  23648	   1008	 452517	  6e7a5	before
       425383	  23648	    976	 450007	  6ddd7	after
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2c98fde