1. 06 6月, 2012 1 次提交
  2. 01 11月, 2011 1 次提交
  3. 16 7月, 2011 1 次提交
  4. 08 7月, 2011 2 次提交
    • J
      mac80211: allow driver to generate P1K for IV32 · 42d98795
      Johannes Berg 提交于
      In order to support pre-populating the P1K cache in
      iwlwifi hardware for WoWLAN, we need to calculate
      the P1K for the current IV32. Allow drivers to get
      the P1K for any given IV32 instead of for a given
      packet, but keep the packet-based version around as
      an inline.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42d98795
    • J
      mac80211: fix TKIP races, make API easier to use · 523b02ea
      Johannes Berg 提交于
      Our current TKIP code races against itself on TX
      since we can process multiple packets at the same
      time on different ACs, but they all share the TX
      context for TKIP. This can lead to bad IVs etc.
      
      Also, the crypto offload helper code just obtains
      the P1K/P2K from the cache, and can update it as
      well, but there's no guarantee that packets are
      really processed in order.
      
      To fix these issues, first introduce a spinlock
      that will protect the IV16/IV32 values in the TX
      context. This first step makes sure that we don't
      assign the same IV multiple times or get confused
      in other ways.
      
      Secondly, change the way the P1K cache works. I
      add a field "p1k_iv32" that stores the value of
      the IV32 when the P1K was last recomputed, and
      if different from the last time, then a new P1K
      is recomputed. This can cause the P1K computation
      to flip back and forth if packets are processed
      out of order. All this also happens under the new
      spinlock.
      
      Finally, because there are argument differences,
      split up the ieee80211_get_tkip_key() API into
      ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
      and give them the correct arguments.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      523b02ea
  5. 05 4月, 2011 1 次提交
  6. 09 7月, 2010 1 次提交
    • J
      mac80211: remove wep dependency · 3473187d
      John W. Linville 提交于
      The current mac80211 code assumes that WEP is always available.  If WEP
      fails to initialize, ieee80211_register_hw will always fail.
      
      In some cases (e.g. FIPS certification), the cryptography used by WEP is
      unavailable.  However, in such cases there is no good reason why CCMP
      encryption (or even no link level encryption) cannot be used.  So, this
      patch removes mac80211's assumption that WEP (and TKIP) will always be
      available for use.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3473187d
  7. 23 1月, 2010 1 次提交
  8. 20 1月, 2010 1 次提交
    • J
      mac80211: move control.hw_key assignment · 813d7669
      Johannes Berg 提交于
      When mac80211 asks a driver to encrypt a frame, it
      must assign the control.hw_key pointer for it to
      know which key to use etc. Currently, mac80211 does
      this whenever it would software-encrypt a frame.
      
      Change the logic of this code to assign the hw_key
      pointer when selecting the key, and later check it
      when deciding whether to encrypt the frame or let
      it be encrypted by the hardware. This allows us to
      later simply skip the encryption function since it
      no longer modifies the TX control.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      813d7669
  9. 23 12月, 2009 1 次提交
  10. 19 11月, 2009 1 次提交
  11. 07 5月, 2009 1 次提交
  12. 28 10月, 2008 1 次提交
  13. 16 9月, 2008 1 次提交
  14. 27 6月, 2008 2 次提交
  15. 15 6月, 2008 3 次提交
  16. 22 5月, 2008 4 次提交
  17. 15 5月, 2008 1 次提交
  18. 01 5月, 2008 1 次提交
  19. 09 4月, 2008 1 次提交
  20. 26 3月, 2008 2 次提交
  21. 11 10月, 2007 3 次提交
  22. 06 5月, 2007 1 次提交