1. 10 Apr, 2012 3 commits
  2. 09 Apr, 2012 4 commits
  3. 15 Mar, 2012 1 commit
  4. 13 Mar, 2012 2 commits
    • Paul Stewart's avatar
      mac80211: Don't let regulatory make us deaf · 3117bbdb
      Paul Stewart authored
      When regulatory information changes our HT behavior (e.g,
      when we get a country code from the AP we have just associated
      with), we should use this information to change the power with
      which we transmit, and what channels we transmit.  Sometimes
      the channel parameters we derive from regulatory information
      contradicts the parameters we used in association.  For example,
      we could have associated specifying HT40, but the regulatory
      rules we apply may forbid HT40 operation.
      In the situation above, we should reconfigure ourselves to
      transmit in HT20 only, however it makes no sense for us to
      disable receive in HT40, since if we associated with these
      parameters, the AP has every reason to expect we can and
      will receive packets this way.  The code in mac80211 does
      not have the capability of sending the appropriate action
      frames to signal a change in HT behaviour so the AP has
      no clue we can no longer receive frames encoded this way.
      In some broken AP implementations, this can leave us
      effectively deaf if the AP never retries in lower HT rates.
      This change breaks up the channel_type parameter in the
      ieee80211_enable_ht function into a separate receive and
      transmit part.  It honors the channel flags set by regulatory
      in order to configure the rate control algorithm, but uses
      the capability flags to configure the channel on the radio,
      since these were used in association to set the AP's transmit
      Signed-off-by: default avatarPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Reviewed-by: default avatarLuis R Rodriguez <mcgrof@frijolero.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: rename bss_conf timestamp to last_tsf · e9ac0745
      Johannes Berg authored
      This value is not really very useful by itself,
      yet some drivers (including iwlwifi until I can
      figure out what it should do) use it. At least
      rename it to "last_tsf" to indicate the meaning
      and add a note that it may be really old.
      I suspect the value may become useful combined
      with the rx_status->mactime, but we don't (yet)
      store that value and pass it to the driver.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 12 Mar, 2012 8 commits
  6. 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>
  7. 05 Mar, 2012 2 commits
  8. 29 Feb, 2012 4 commits
  9. 27 Feb, 2012 4 commits
  10. 06 Feb, 2012 4 commits
    • Johannes Berg's avatar
      mac80211: redesign auth/assoc · 66e67e41
      Johannes Berg authored
      This is the second part of the auth/assoc redesign,
      the mac80211 part. This moves the auth/assoc code
      out of the work abstraction and into the MLME, so
      that we don't flip channels all the time etc.
      The only downside is that when we are associated,
      we need to drop the association in order to create
      a connection to another AP, but for most drivers
      this is actually desirable and the ability to do
      was never used by any applications. If we want to
      implement resource reservation with FT-OTA, we'd
      probably best do it with explicit R-O-C in wpa_s.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: stop tracking authenticated state · 95de817b
      Johannes Berg authored
      To track authenticated state seems to have been
      a design mistake in cfg80211. It is possible to
      have out of band authentication (FT), tracking
      multiple authentications caused more problems
      than it ever helped, and the implementation in
      mac80211 is too complex.
      Remove all this complexity, and let userspace
      do whatever it wants to, mac80211 can deal with
      that just fine. Association is still tracked of
      course, but authentication no longer is. Local
      auth state changes are thus no longer of value,
      so ignore them completely.
      This will also help implement SAE -- asking the
      driver to do an authentication is now almost
      equivalent to sending an authentication frame,
      with the exception of shared key authentication
      which is still handled completely.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: remove dummy STA support · 7852e361
      Johannes Berg authored
      The dummy STA support was added because I didn't
      want to change the driver API at the time. Now
      that we have state transitions triggering station
      add/remove in the driver, we only call add once a
      station reaches ASSOCIATED, so we can remove the
      dummy station stuff again.
      While at it, tighten the RX check and accept only
      port control (EAP) frames from the AP station if
      it's not associated yet -- in other cases there's
      no race.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: move managed mode station state modification · c8987876
      Johannes Berg authored
      Move the station state modification right before insert,
      this just makes the current code more readable (you can
      tell that it's before insertion looking at a single
      screenful of code) right now, but some upcoming changes
      will require this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 30 Jan, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: station state transition error handling · 83d5cc01
      Johannes Berg authored
      In the future, when we start notifying drivers,
      state transitions could potentially fail. To make
      it easier to distinguish between programming bugs
      and driver failures:
       * rename sta_info_move_state() to
         sta_info_pre_move_state() which can only be
         called before the station is inserted (and
         check this with a new station flag).
       * rename sta_info_move_state_checked() to just
         plain sta_info_move_state(), as it will be
         the regular function that can fail for more
         than just one reason (bad transition or an
         error from the driver)
      This makes the programming model easier -- one of
      the functions can only be called before insertion
      and can't fail, the other can fail.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  12. 27 Jan, 2012 2 commits
  13. 24 Jan, 2012 1 commit
  14. 18 Jan, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: fix work removal on deauth request · bc4934bc
      Johannes Berg authored
      When deauth is requested while an auth or assoc
      work item is in progress, we currently delete it
      without regard for any state it might need to
      clean up. Fix it by cleaning up for those items.
      In the case Pontus found, the problem manifested
      itself as such:
      authenticate with 00:23:69:aa:dd:7b (try 1)
      failed to insert Dummy STA entry for the AP (error -17)
      deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)
      It could also happen differently if the driver
      uses the tx_sync callback.
      We can't just call the ->done() method of the work
      items because that will lock up due to the locking
      in cfg80211. This fix isn't very clean, but that
      seems acceptable since I have patches pending to
      remove this code completely.
      Cc: stable@vger.kernel.org
      Reported-by: default avatarPontus Fuchs <pontus.fuchs@gmail.com>
      Tested-by: default avatarPontus Fuchs <pontus.fuchs@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  15. 04 Jan, 2012 1 commit
  16. 19 Dec, 2011 1 commit