1. 20 Aug, 2012 1 commit
  2. 31 Jul, 2012 3 commits
    • Johannes Berg's avatar
      mac80211: fix current vs. operating channel in preq/beacon · 6b77863b
      Johannes Berg authored
      When sending probe requests, e.g. during software scanning,
      these will go out on the *current* channel, so their IEs
      need to be built from the current channel. At other times,
      e.g. for beacons or probe request templates, the IEs will
      be used on the *operating* channel and using the current
      channel instead might result in errors.
      Add the appropriate parameters to respect the difference.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: use oper_channel in utils and config · 679ef4ea
      Johannes Berg authored
      Using hw.conf.channel is wrong as it could be the
      temporary channel if any function like the beacon
      get function is called while scanning or during
      other temporary out-of-channel activities.
      Use oper_channel instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Eliad Peller's avatar
      mac80211: add PS flag to bss_conf · ab095877
      Eliad Peller authored
      Currently, ps mode is indicated per device (rather than
      per interface), which doesn't make a lot of sense.
      Moreover, there are subtle bugs caused by the inability
      to indicate ps change along with other changes
      (e.g. when the AP deauth us, we'd like to indicate
      CHANGED_PS | CHANGED_ASSOC, as changing PS before
      notifying about disassociation will result in null-packets
      being sent (if IEEE80211_HW_SUPPORTS_DYNAMIC_PS) while
      the sta is already disconnected.)
      Keep the current per-device notifications, and add
      parallel per-vif notifications.
      In order to keep it simple, the per-device ps and
      the per-vif ps are orthogonal - the per-vif ps
      configuration is determined only by the user
      configuration (enable/disable) and the connection
      state, and is not affected by other vifs state and
      (temporary) dynamic_ps/offchannel operations
      (unlike per-device ps).
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  3. 12 Jul, 2012 2 commits
  4. 06 Jul, 2012 2 commits
  5. 02 Jul, 2012 1 commit
  6. 28 Jun, 2012 1 commit
  7. 18 Jun, 2012 1 commit
  8. 06 Jun, 2012 2 commits
  9. 04 Jun, 2012 1 commit
  10. 29 May, 2012 1 commit
  11. 08 May, 2012 1 commit
  12. 24 Apr, 2012 1 commit
  13. 23 Apr, 2012 2 commits
  14. 16 Apr, 2012 1 commit
  15. 13 Apr, 2012 1 commit
  16. 11 Apr, 2012 4 commits
  17. 10 Apr, 2012 5 commits
  18. 09 Apr, 2012 1 commit
  19. 07 Mar, 2012 1 commit
    • Paul Stewart's avatar
      mac80211: Filter duplicate IE ids · fcff4f10
      Paul Stewart authored
      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: default avatarPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Eliad Peller <eliad@wizery.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  20. 05 Mar, 2012 1 commit
  21. 27 Feb, 2012 1 commit
  22. 06 Feb, 2012 3 commits
  23. 27 Jan, 2012 1 commit
  24. 24 Jan, 2012 1 commit
  25. 04 Jan, 2012 1 commit