1. 14 5月, 2009 3 次提交
  2. 12 5月, 2009 1 次提交
    • J
      nl80211 : Add support for configuring MFP · dc6382ce
      Jouni Malinen 提交于
      NL80211_CMD_ASSOCIATE request must be able to indicate whether
      management frame protection (IEEE 802.11w) is being used. mac80211 was
      able to use MFP in client mode only with WEXT, but the new
      NL80211_ATTR_USE_MFP attribute will allow this to be done with
      nl80211, too.
      
      Since we are currently using nl80211 for MFP only with drivers that
      use user space SME, only MFP disabled and required values are
      used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
      be extended with MFP optional in the future, if that is needed with
      some drivers (e.g., if the RSN IE is generated by the driver).
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dc6382ce
  3. 23 4月, 2009 8 次提交
  4. 28 3月, 2009 4 次提交
    • J
      nl80211: Remove NL80211_CMD_SET_MGMT_EXTRA_IE · 65fc73ac
      Jouni Malinen 提交于
      The functionality that NL80211_CMD_SET_MGMT_EXTRA_IE provided can now
      be achieved with cleaner design by adding IE(s) into
      NL80211_CMD_TRIGGER_SCAN, NL80211_CMD_AUTHENTICATE,
      NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE, and
      NL80211_CMD_DISASSOCIATE.
      
      Since this is a very recently added command and there are no known (or
      known planned) applications using NL80211_CMD_SET_MGMT_EXTRA_IE and
      taken into account how much extra complexity it adds to the IE
      processing we have now (and need to add in the future to fix IE order
      in couple of frames), it looks like the best option is to just remove
      the implementation of this command for now. The enum values themselves
      are left to avoid changing the nl80211 command or attribute numbers.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      65fc73ac
    • J
      nl80211: Add MLME primitives to support external SME · 636a5d36
      Jouni Malinen 提交于
      This patch adds new nl80211 commands to allow user space to request
      authentication and association (and also deauthentication and
      disassociation). The commands are structured to allow separate
      authentication and association steps, i.e., the interface between
      kernel and user space is similar to the MLME SAP interface in IEEE
      802.11 standard and an user space application takes the role of the
      SME.
      
      The patch introduces MLME-AUTHENTICATE.request,
      MLME-{,RE}ASSOCIATE.request, MLME-DEAUTHENTICATE.request, and
      MLME-DISASSOCIATE.request primitives. The authentication and
      association commands request the actual operations in two steps
      (assuming the driver supports this; if not, separate authentication
      step is skipped; this could end up being a separate "connect"
      command).
      
      The initial implementation for mac80211 uses the current
      net/mac80211/mlme.c for actual sending and processing of management
      frames and the new nl80211 commands will just stop the current state
      machine from moving automatically from authentication to association.
      Future cleanup may move more of the MLME operations into cfg80211.
      
      The goal of this design is to provide more control of authentication and
      association process to user space without having to move the full MLME
      implementation. This should be enough to allow IEEE 802.11r FT protocol
      and 802.11s SAE authentication to be implemented. Obviously, this will
      also bring the extra benefit of not having to use WEXT for association
      requests with mac80211. An example implementation of a user space SME
      using the new nl80211 commands is available for wpa_supplicant.
      
      This patch is enough to get IEEE 802.11r FT protocol working with
      over-the-air mechanism (over-the-DS will need additional MLME
      primitives for handling the FT Action frames).
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      636a5d36
    • J
      nl80211: Event notifications for MLME events · 6039f6d2
      Jouni Malinen 提交于
      Add new nl80211 event notifications (and a new multicast group, "mlme")
      for informing user space about received and processed Authentication,
      (Re)Association Response, Deauthentication, and Disassociation frames in
      station and IBSS modes (i.e., MLME SAP interface primitives
      MLME-AUTHENTICATE.confirm, MLME-ASSOCIATE.confirm,
      MLME-REASSOCIATE.confirm, MLME-DEAUTHENTICATE.indicate, and
      MLME-DISASSOCIATE.indication). The event data is encapsulated as the 802.11
      management frame since we already have the frame in that format and it
      includes all the needed information.
      
      This is the initial step in providing MLME SAP interface for
      authentication and association with nl80211. In other words, kernel code
      will act as the MLME and a user space application can control it as the
      SME.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6039f6d2
    • J
      nl80211: export supported commands · 8fdc621d
      Johannes Berg 提交于
      This makes nl80211 export the supported commands (command groups)
      per wiphy so userspace has an idea what it can do -- this will be
      required reading for userspace when we introduce auth/assoc /or/
      connect for older hardware that cannot separate auth and assoc.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8fdc621d
  5. 17 3月, 2009 2 次提交
  6. 28 2月, 2009 1 次提交
  7. 14 2月, 2009 1 次提交
  8. 10 2月, 2009 1 次提交
  9. 30 1月, 2009 4 次提交
  10. 20 12月, 2008 2 次提交
  11. 05 12月, 2008 2 次提交
  12. 26 11月, 2008 2 次提交
  13. 11 11月, 2008 2 次提交
  14. 01 11月, 2008 2 次提交
  15. 16 9月, 2008 1 次提交
    • L
      cfg80211: Add new wireless regulatory infrastructure · b2e1b302
      Luis R. Rodriguez 提交于
      This adds the new wireless regulatory infrastructure. The
      main motiviation behind this was to centralize regulatory
      code as each driver was implementing their own regulatory solution,
      and to replace the initial centralized code we have where:
      
      * only 3 regulatory domains are supported: US, JP and EU
      * regulatory domains can only be changed through module parameter
      * all rules were built statically in the kernel
      
      We now have support for regulatory domains for many countries
      and regulatory domains are now queried through a userspace agent
      through udev allowing distributions to update regulatory rules
      without updating the kernel.
      
      Each driver can regulatory_hint() a regulatory domain
      based on either their EEPROM mapped regulatory domain value to a
      respective ISO/IEC 3166-1 country code or pass an internally built
      regulatory domain. We also add support to let the user set the
      regulatory domain through userspace in case of faulty EEPROMs to
      further help compliance.
      
      Support for world roaming will be added soon for cards capable of
      this.
      
      For more information see:
      
      http://wireless.kernel.org/en/developers/Regulatory/CRDA
      
      For now we leave an option to enable the old module parameter,
      ieee80211_regdom, and to build the 3 old regdomains statically
      (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY.
      These old static definitions and the module parameter is being
      scheduled for removal for 2.6.29. Note that if you use this
      you won't make use of a world regulatory domain as its pointless.
      If you leave this option enabled and if CRDA is present and you
      use US or JP we will try to ask CRDA to update us a regulatory
      domain for us.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b2e1b302
  16. 06 9月, 2008 1 次提交
  17. 30 8月, 2008 2 次提交
  18. 27 6月, 2008 1 次提交