1. 23 8月, 2011 4 次提交
  2. 20 7月, 2011 1 次提交
  3. 28 6月, 2011 1 次提交
  4. 02 6月, 2011 1 次提交
  5. 12 5月, 2011 3 次提交
  6. 05 4月, 2011 1 次提交
  7. 10 3月, 2011 1 次提交
  8. 14 1月, 2011 1 次提交
  9. 21 12月, 2010 2 次提交
  10. 14 12月, 2010 1 次提交
  11. 09 12月, 2010 1 次提交
  12. 12 10月, 2010 1 次提交
  13. 20 4月, 2010 1 次提交
  14. 09 4月, 2010 1 次提交
  15. 08 4月, 2010 1 次提交
    • J
      mac80211: clean up/fix aggregation code · 098a6070
      Johannes Berg 提交于
      The aggregation code has a number of quirks, like
      inventing an unneeded WLAN_BACK_TIMER value and
      leaking memory under certain circumstances during
      station destruction. Fix these issues by using
      the regular aggregation session teardown code and
      blocking new aggregation sessions, all before the
      station is really destructed.
      
      As a side effect, this gets rid of the long code
      block to destroy aggregation safely.
      
      Additionally, rename tid_state_rx which can only
      have the values IDLE and OPERATIONAL to
      tid_active_rx to make it easier to understand
      that there is no bitwise stuff going on on the
      RX side -- the TX side remains because it needs
      to keep track of the driver and peer states.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      098a6070
  16. 23 1月, 2010 1 次提交
  17. 13 1月, 2010 3 次提交
  18. 29 12月, 2009 1 次提交
    • J
      mac80211: split up and insert custom IEs correctly · 8e664fb3
      Johannes Berg 提交于
      Currently, we insert all user-specified IEs before the HT
      IE for association, and after the HT IE for probe requests.
      For association, that's correct only if the user-specified
      IEs are RSN only, incorrect in all other cases including
      WPA. Change this to split apart the user-specified IEs in
      two places for association: before the HT IE (e.g. RSN),
      after the HT IE (generally empty right now I think?) and
      after WMM (all other vendor-specific IEs). For probes,
      split the IEs in different places to be correct according
      to the spec.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e664fb3
  19. 23 12月, 2009 2 次提交
  20. 22 12月, 2009 1 次提交
    • J
      mac80211: fix peer HT capabilities · 9a418af5
      Johannes Berg 提交于
      I noticed yesterday, because Jeff had noticed
      a speed regression, cf. bug
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
      that the SM PS settings for peers were wrong.
      Instead of overwriting the SM PS settings with
      the local bits, we need to keep the remote bits.
      
      The bug was part of the original HT code from
      over two years ago, but unfortunately nobody
      noticed that it makes no sense -- we shouldn't
      be overwriting the peer's setting with our own
      but rather keep it intact when masking the peer
      capabilities with our own.
      
      While fixing that, I noticed that the masking of
      capabilities is completely useless for most of
      the bits, so also fix those other bits.
      
      Finally, I also noticed that PSMP_SUPPORT no
      longer exists in the final 802.11n version, so
      also remove that.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9a418af5
  21. 29 11月, 2009 1 次提交
  22. 19 11月, 2009 1 次提交
  23. 14 11月, 2009 1 次提交
  24. 12 11月, 2009 1 次提交
  25. 31 10月, 2009 1 次提交
  26. 29 8月, 2009 1 次提交
  27. 28 7月, 2009 1 次提交
  28. 11 7月, 2009 1 次提交
  29. 04 6月, 2009 1 次提交
  30. 23 5月, 2009 1 次提交
  31. 12 5月, 2009 1 次提交
    • J
      mac80211: Robust Action frame categories for MFP · 528769cf
      Jouni Malinen 提交于
      IEEE 802.11w/D9.0 introduces a mechanism for Action field Category
      values to be used to select which Action frames are Robust. Public and
      Vendor-specific categories are marked as not Robust in IEEE 802.11w;
      HT will be marked not Robust in IEEE 802.11n. A new Vendor-specific
      Protected category is allocated for Robust vendor-specific Action
      frames. Another new category, Protected Dual of Action, is introduced
      for protecting some existing Public Action frames (e.g., IEEE 802.11y
      protected enablement).
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      528769cf