1. 23 Nov, 2012 3 commits
    • Johannes Berg's avatar
      mac80211: disable HT advertising unless AP supports it · 03ae834f
      Johannes Berg authored
      If the AP doesn't support HT, or more importantly if
      it does but we have to disable it because its IEs are
      broken, don't advertise HT support in our association
      request. Otherwise, we configure our channel to be a
      20 MHz non-HT channel but the AP might still think we
      support HT, or even 40 MHz.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: rename IEEE80211_STA_DISABLE_11N to HT · a8243b72
      Johannes Berg authored
      Since the 11n spec amendment was rolled into the
      2012 version, "11n" no longer makes sense. Use
      "HT" instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: fix RX chains configuration · 76c5fa0f
      Johannes Berg authored
      If the driver doesn't support 40 MHz channels, then
      mac80211 erroneously sets number of RX chains to one
      although the number of chains is independent of the
      support for 40 MHz channels.
      Fix this by checking the 40 MHz support only for the
      code that sets the 40 MHz channel not the complete
      HT code block.
      This also means the HT20 channel type will always be
      set in the changed code block so there's no need to
      set it in case we override the AP due to invalid IEs
      in the probe response/beacon.
      The indentation is a bit quirky, but I'm rewriting
      this code for VHT support so this will change again
      very soon.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  2. 06 Nov, 2012 1 commit
  3. 05 Nov, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: send deauth only with channel context · 86552017
      Johannes Berg authored
      When userspace asks to deauthenticate and we're just
      authenticated (or still authenticating) send a deauth
      frame instead of deleting the auth request.
      On the other hand, if we've just disassociated and
      therefore deleted all our state already, drop the
      deauth request because we no longer have a channel
      context to send it on.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  4. 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>
  5. 25 Oct, 2012 1 commit
  6. 18 Oct, 2012 1 commit
  7. 17 Oct, 2012 8 commits
  8. 15 Oct, 2012 1 commit
  9. 21 Sep, 2012 1 commit
  10. 14 Sep, 2012 2 commits
  11. 07 Sep, 2012 1 commit
  12. 06 Sep, 2012 2 commits
  13. 04 Sep, 2012 1 commit
  14. 20 Aug, 2012 6 commits
  15. 01 Aug, 2012 2 commits
  16. 31 Jul, 2012 8 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 managed mlme · 568d6e28
      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>
    • Johannes Berg's avatar
      mac80211: set channel only once during auth/assoc · b17166a7
      Johannes Berg authored
      There's no need to set up the channel during auth
      and again during assoc, just do it once. Currently
      this doesn't result in any changes since calling
      hw_config() with an unchanged channel will return
      early, but with the channel context work this has
      an impact on channel context assignment.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: rename sta to new_sta · 13e0c8e3
      Johannes Berg authored
      In ieee80211_prep_connection(), the station (if not NULL)
      is the new station (representing the AP) that needs to be
      added. Rename the variable to "new_sta" to clarify this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: supress HT/VHT disable if not supported · 1b49de26
      Johannes Berg authored
      If HT/VHT isn't supported by us we shouldn't print
      a message that we disabled it, do that only if the
      AP didn't support WMM and we therefore disable it.
      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>
    • Emmanuel Grumbach's avatar
      mac80211: don't call mgd_prepare_tx when associated · 8c7d857c
      Emmanuel Grumbach authored
      This doesn't make any sense since we are expected to be on
      the medium or at least to Tx only when we are on the right
      channel and the AP/GO can hear us.
      Move the call to mgd_prepare_tx() for deauth to be only
      done in case we're sending a deauth while not associated.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: don't react to beacon loss if HW monitoring · 7eeff74c
      Johannes Berg authored
      If the HW is monitoring connection loss (as advertised
      by IEEE80211_HW_CONNECTION_MONITOR) but not filtering
      beacons (IEEE80211_VIF_BEACON_FILTER) then mac80211 will
      still start the beacon loss timer and if a few beacons
      are lost, e.g. due to scanning, drop the connection.
      If the hardware doesn't advertise connection monitoring,
      then it won't drop the connection right away but probe
      the AP, which is intended, but due to the logic in the
      timer when connection monitoring is done it assumes the
      connection was actually lost.
      Fix this problem by not starting the timer when the HW
      does connection monitoring.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>