1. 11 4月, 2012 2 次提交
  2. 10 4月, 2012 1 次提交
  3. 08 3月, 2012 1 次提交
    • P
      mac80211: Filter duplicate IE ids · fcff4f10
      Paul Stewart 提交于
      mac80211 is lenient with respect to reception of corrupted beacons.
      Even if the frame is corrupted as a whole, the available IE elements
      are still passed back and accepted, sometimes replacing legitimate
      data.  It is unknown to what extent this "feature" is made use of,
      but it is clear that in some cases, this is detrimental.  One such
      case is reported in http://crosbug.com/26832 where an AP corrupts
      its beacons but not its probe responses.
      
      One approach would be to completely reject frames with invaid data
      (for example, if the last tag extends beyond the end of the enclosing
      PDU).  The enclosed approach is much more conservative: we simply
      prevent later IEs from overwriting the state from previous ones.
      This approach hopes that there might be some salient data in the
      IE stream before the corruption, and seeks to at least prevent that
      data from being overwritten.  This approach will fix the case above.
      
      Further, we flag element structures that contain data we think might
      be corrupted, so that as we fill the mac80211 BSS structure, we try
      not to replace data from an un-corrupted probe response with that
      of a corrupted beacon, for example.
      
      Short of any statistics gathering in the various forms of AP breakage,
      it's not possible to ascertain the side effects of more stringent
      discarding of data.
      Signed-off-by: NPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Eliad Peller <eliad@wizery.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fcff4f10
  4. 06 3月, 2012 1 次提交
  5. 28 2月, 2012 1 次提交
  6. 07 2月, 2012 3 次提交
  7. 28 1月, 2012 1 次提交
  8. 25 1月, 2012 1 次提交
  9. 05 1月, 2012 1 次提交
  10. 14 12月, 2011 1 次提交
  11. 07 12月, 2011 1 次提交
  12. 01 12月, 2011 1 次提交
  13. 29 11月, 2011 1 次提交
  14. 22 11月, 2011 3 次提交
  15. 12 11月, 2011 2 次提交
  16. 10 11月, 2011 3 次提交
  17. 09 11月, 2011 1 次提交
  18. 01 11月, 2011 1 次提交
  19. 01 10月, 2011 3 次提交
  20. 28 9月, 2011 2 次提交
  21. 15 9月, 2011 1 次提交
  22. 14 9月, 2011 1 次提交
  23. 13 8月, 2011 1 次提交
  24. 11 8月, 2011 1 次提交
  25. 20 7月, 2011 1 次提交
  26. 19 7月, 2011 1 次提交
  27. 16 7月, 2011 1 次提交
  28. 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
  29. 12 7月, 2011 1 次提交