1. 20 Nov, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: fix channel context suspend/reconfig handling · fe5f2559
      Johannes Berg authored
      
      
      Sujith reported warnings with suspend/resume due to
      channel contexts. When I looked into it, I realised
      that the code was completely broken as it unassigned
      the channel contexts when suspending, which actually
      means they are destroyed.
      
      Eliad Peller then pointed out that we also need to
      remove the channel contexts from the driver. When I
      looked into this, I also noticed that the code isn't
      handling the virtual monitor interface correctly (if
      it exists.)
      
      Fix this by calling just the driver methods (if they
      are implemented) instead of using the channel context
      management code. Also add reconfiguration for the
      virtual monitor interface.
      
      Reported-by: default avatarSujith Manoharan <sujith@msujith.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe5f2559
  2. 19 Nov, 2012 1 commit
  3. 13 Nov, 2012 1 commit
  4. 09 Nov, 2012 3 commits
  5. 30 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: handle TX power per virtual interface · 1ea6f9c0
      Johannes Berg authored
      
      
      Even before channel contexts/multi-channel, having a
      single global TX power limit was already problematic,
      in particular if two managed interfaces connected to
      two APs with different power constraints. The channel
      context introduction completely broke this though and
      in fact I had disabled TX power configuration there
      for drivers using channel contexts.
      
      Change everything to track TX power per interface so
      that different user settings and different channel
      maxima are treated correctly. Also continue tracking
      the global TX power though for compatibility with
      applications that attempt to configure the wiphy's
      TX power globally.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1ea6f9c0
  6. 26 Oct, 2012 1 commit
  7. 25 Oct, 2012 1 commit
  8. 24 Oct, 2012 1 commit
  9. 17 Oct, 2012 5 commits
  10. 15 Oct, 2012 1 commit
  11. 14 Sep, 2012 1 commit
  12. 07 Sep, 2012 1 commit
  13. 06 Sep, 2012 1 commit
  14. 20 Aug, 2012 4 commits
    • Johannes Berg's avatar
      mac80211: pass channel to ieee80211_send_probe_req · fe94fe05
      Johannes Berg authored
      
      
      In multi-channel scenarios, the channel that we will
      transmit a probe request on isn't always the current
      channel (which will be NULL anyway) but will instead
      be the channel that the AP is on. Pass the channel
      to the ieee80211_send_probe_req() function so it can
      be used in the different scenarios. The scan code
      continues to pass the current channel, of course.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe94fe05
    • Johannes Berg's avatar
      mac80211: support P2P Device abstraction · f142c6b9
      Johannes Berg authored
      
      
      After cfg80211 got a P2P Device abstraction, add
      support to mac80211. Whether it really is supported
      or not will depend on whether or not the driver has
      support for it, but mac80211 needs to change to be
      able to support drivers that need a P2P Device.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f142c6b9
    • Johannes Berg's avatar
      cfg80211: add P2P Device abstraction · 98104fde
      Johannes Berg authored
      
      
      In order to support using a different MAC address
      for the P2P Device address we must first have a
      P2P Device abstraction that can be assigned a MAC
      address.
      
      This abstraction will also be useful to support
      offloading P2P operations to the device, e.g.
      periodic listen for discoverability.
      
      Currently, the driver is responsible for assigning
      a MAC address to the P2P Device, but this could be
      changed by allowing a MAC address to be given to
      the NEW_INTERFACE command.
      
      As it has no associated netdev, a P2P Device can
      only be identified by its wdev identifier but the
      previous patches allowed using the wdev identifier
      in various APIs, e.g. remain-on-channel.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      98104fde
    • Johannes Berg's avatar
      mac80211: check size of channel switch IE when parsing · 5bc1420b
      Johannes Berg authored
      
      
      The channel switch IE has a fixed size, so we can
      discard it in parsing if it's not the right size
      and use the right struct pointer.
      
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5bc1420b
  15. 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>
      6b77863b
    • 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>
      679ef4ea
    • 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>
      ab095877
  16. 12 Jul, 2012 2 commits
  17. 06 Jul, 2012 2 commits
  18. 02 Jul, 2012 1 commit
  19. 28 Jun, 2012 1 commit
  20. 18 Jun, 2012 1 commit
  21. 06 Jun, 2012 2 commits
  22. 04 Jun, 2012 1 commit
  23. 29 May, 2012 1 commit
  24. 09 May, 2012 1 commit
  25. 24 Apr, 2012 1 commit
  26. 23 Apr, 2012 1 commit