1. 01 10月, 2011 1 次提交
  2. 28 9月, 2011 2 次提交
  3. 21 9月, 2011 1 次提交
  4. 17 9月, 2011 1 次提交
  5. 15 9月, 2011 2 次提交
  6. 14 9月, 2011 1 次提交
  7. 26 8月, 2011 1 次提交
  8. 09 8月, 2011 2 次提交
  9. 21 7月, 2011 1 次提交
  10. 16 7月, 2011 2 次提交
  11. 14 7月, 2011 1 次提交
    • J
      mac80211: allow driver to disconnect after resume · 95acac61
      Johannes Berg 提交于
      In WoWLAN, devices may use crypto keys for TX/RX
      and could also implement GTK rekeying. If the
      driver isn't able to retrieve replay counters and
      similar information from the device upon resume,
      or if the device isn't responsive due to platform
      issues, it isn't safe to keep the connection up
      as GTK rekey messages from during the sleep time
      could be replayed against it.
      
      The only protection against that is disconnecting
      from the AP. Modifying mac80211 to do that while
      it is resuming would be very complex and invasive
      in the case that the driver requires a reconfig,
      so do it after it has resumed completely. In that
      case, however, packets might be replayed since it
      can then only happen after TX/RX are up again, so
      mark keys for interfaces that need to disconnect
      as "tainted" and drop all packets that are sent
      or received with those keys.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      95acac61
  12. 12 7月, 2011 1 次提交
  13. 08 7月, 2011 3 次提交
    • 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: allow drivers to access key sequence counter · 3ea542d3
      Johannes Berg 提交于
      In order to implement GTK rekeying, the device needs
      to be able to encrypt frames with the right PN/IV and
      check the PN/IV in RX frames. To be able to tell it
      about all those counters, we need to be able to get
      them from mac80211, this adds the required API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ea542d3
    • 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
  14. 07 7月, 2011 2 次提交
  15. 06 7月, 2011 1 次提交
  16. 30 6月, 2011 1 次提交
  17. 18 6月, 2011 1 次提交
  18. 11 6月, 2011 1 次提交
  19. 08 6月, 2011 1 次提交
    • S
      mac80211: Stop BA session event from device · f41ccd71
      Shahar Levi 提交于
      Some devices support BT/WLAN co-existence algorigthms.
      In order not to harm the system performance and user experience, the device
      requests not to allow any RX BA session and tear down existing RX BA sessions
      based on system constraints such as periodic BT activity that needs to limit
      WLAN activity (eg.SCO or A2DP).
      In such cases, the intention is to limit the duration of the RX PPDU and
      therefore prevent the peer device to use A-MPDU aggregation.
      
      Adding ieee80211_stop_rx_ba_session() callback
      that can be used by the driver to stop existing BA sessions.
      Signed-off-by: NShahar Levi <shahar_levi@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f41ccd71
  20. 02 6月, 2011 1 次提交
  21. 25 5月, 2011 1 次提交
  22. 23 5月, 2011 1 次提交
  23. 12 5月, 2011 1 次提交
  24. 06 5月, 2011 1 次提交
  25. 29 4月, 2011 2 次提交
  26. 20 4月, 2011 1 次提交
  27. 13 4月, 2011 1 次提交
    • V
      mac80211: Check for queued frames before entering power save. · e8306f98
      Vivek Natarajan 提交于
      In a highly noisy environment, the tx rate of the driver drops and
      the application slows down since it has not yet received ACKs for
      the frames already queued in the hardware. Since this ACK may take
      more than 100ms, stopping the dev queues for entering PS at this
      stage breaks applications, WMM test cases in my testing.
      If there are frames already pending in the tx queue, postponing the
      PS logic helps to avoid redundant queue stops. When power save is
      enabled by default and in a noisy environment, this API certainly
      helps in improving the average throughput.
      Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e8306f98
  28. 05 4月, 2011 1 次提交
  29. 31 3月, 2011 1 次提交
  30. 22 3月, 2011 1 次提交
  31. 12 3月, 2011 1 次提交
  32. 26 2月, 2011 1 次提交