1. 28 3月, 2009 3 次提交
    • 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: rework locking · 3b85875a
      Johannes Berg 提交于
      When I added scanning to cfg80211, we got a lock dependency like this:
      	rtnl --> cfg80211_mtx
      
      nl80211, on the other hand, has the reverse lock dependency:
      	cfg80211_mtx --> rtnl
      
      which clearly is a bad idea. This patch reworks nl80211 to take these
      two locks in the other order to fix the possible, and easily
      triggerable, deadlock.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3b85875a
    • 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
  2. 21 3月, 2009 1 次提交
  3. 17 3月, 2009 1 次提交
  4. 28 2月, 2009 10 次提交
  5. 14 2月, 2009 1 次提交
  6. 10 2月, 2009 1 次提交
  7. 30 1月, 2009 3 次提交
  8. 20 12月, 2008 2 次提交
  9. 13 12月, 2008 1 次提交
  10. 05 12月, 2008 1 次提交
  11. 26 11月, 2008 3 次提交
  12. 11 11月, 2008 2 次提交
  13. 01 11月, 2008 5 次提交
  14. 25 9月, 2008 3 次提交
  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 1 次提交