1. 05 8月, 2009 1 次提交
  2. 30 7月, 2009 1 次提交
  3. 28 7月, 2009 1 次提交
    • J
      cfg80211: make aware of net namespaces · 463d0183
      Johannes Berg 提交于
      In order to make cfg80211/nl80211 aware of network namespaces,
      we have to do the following things:
      
       * del_virtual_intf method takes an interface index rather
         than a netdev pointer - simply change this
      
       * nl80211 uses init_net a lot, it changes to use the sender's
         network namespace
      
       * scan requests use the interface index, hold a netdev pointer
         and reference instead
      
       * we want a wiphy and its associated virtual interfaces to be
         in one netns together, so
          - we need to be able to change ns for a given interface, so
            export dev_change_net_namespace()
          - for each virtual interface set the NETIF_F_NETNS_LOCAL
            flag, and clear that flag only when the wiphy changes ns,
            to disallow breaking this invariant
      
       * when a network namespace goes away, we need to reparent the
         wiphy to init_net
      
       * cfg80211 users that support creating virtual interfaces must
         create them in the wiphy's namespace, currently this affects
         only mac80211
      
      The end result is that you can now switch an entire wiphy into
      a different network namespace with the new command
      	iw phy#<idx> set netns <pid>
      and all virtual interfaces will follow (or the operation fails).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      463d0183
  4. 25 7月, 2009 1 次提交
    • J
      cfg80211: rework key operation · fffd0934
      Johannes Berg 提交于
      This reworks the key operation in cfg80211, and now only
      allows, from userspace, configuring keys (via nl80211)
      after the connection has been established (in managed
      mode), the IBSS been joined (in IBSS mode), at any time
      (in AP[_VLAN] modes) or never for all the other modes.
      
      In order to do shared key authentication correctly, it
      is now possible to give a WEP key to the AUTH command.
      To configure static WEP keys, these are given to the
      CONNECT or IBSS_JOIN command directly, for a userspace
      SME it is assumed it will configure it properly after
      the connection has been established.
      
      Since mac80211 used to check the default key in IBSS
      mode to see whether or not the network is protected,
      it needs an update in that area, as well as an update
      to make use of the WEP key passed to auth() for shared
      key authentication.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fffd0934
  5. 11 7月, 2009 9 次提交
  6. 04 6月, 2009 1 次提交
  7. 21 5月, 2009 4 次提交
  8. 14 5月, 2009 1 次提交
    • J
      cfg80211: implement wext key handling · 08645126
      Johannes Berg 提交于
      Move key handling wireless extension ioctls from mac80211 to cfg80211
      so that all drivers that implement the cfg80211 operations get wext
      compatibility.
      
      Note that this drops the SIOCGIWENCODE ioctl support for getting
      IW_ENCODE_RESTRICTED/IW_ENCODE_OPEN. This means that iwconfig will
      no longer report "Security mode:open" or "Security mode:restricted"
      for mac80211. However, what we displayed there (the authentication
      algo used) was actually wrong -- linux/wireless.h states that this
      setting is meant to differentiate between "Refuse non-encoded packets"
      and "Accept non-encoded packets".
      
      (Combined with "cfg80211: fix a couple of bugs with key ioctls". -- JWL)
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      08645126
  9. 23 4月, 2009 5 次提交
  10. 18 4月, 2009 1 次提交
  11. 28 3月, 2009 2 次提交
  12. 17 3月, 2009 1 次提交
  13. 28 2月, 2009 7 次提交
  14. 14 2月, 2009 1 次提交
  15. 26 11月, 2008 1 次提交
    • L
      cfg80211/mac80211: Add 802.11d support · 3f2355cb
      Luis R. Rodriguez 提交于
      This adds country IE parsing to mac80211 and enables its usage
      within the new regulatory infrastructure in cfg80211. We parse
      the country IEs only on management beacons for the BSSID you are
      associated to and disregard the IEs when the country and environment
      (indoor, outdoor, any) matches the already processed country IE.
      
      To avoid following misinformed or outdated APs we build and use
      a regulatory domain out of the intersection between what the AP
      provides us on the country IE and what CRDA is aware is allowed
      on the same country.
      
      A secondary device is allowed to follow only the same country IE
      as it make no sense for two devices on a system to be in two
      different countries.
      
      In the case the AP is using country IEs for an incorrect country
      the user may help compliance further by setting the regulatory
      domain before or after the IE is parsed and in that case another
      intersection will be performed.
      
      CONFIG_WIRELESS_OLD_REGULATORY is supported but requires CRDA
      present.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3f2355cb
  16. 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
  17. 01 3月, 2008 1 次提交
    • J
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg 提交于
      This patch creates new cfg80211 wiphy API for channel and bitrate
      registration and converts mac80211 and drivers to the new API. The
      old mac80211 API is completely ripped out. All drivers (except ath5k)
      are updated to the new API, in many cases I expect that optimisations
      can be done.
      
      Along with the regulatory code I've also ripped out the
      IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
      unnecessary if the hardware simply gives us whatever channels it wants
      to support and we then enable/disable them as required, which is pretty
      much required for travelling.
      
      Additionally, the patch adds proper "basic" rate handling for STA
      mode interface, AP mode interface will have to have new API added
      to allow userspace to set the basic rate set, currently it'll be
      empty... However, the basic rate handling will need to be moved to
      the BSS conf stuff.
      
      I do expect there to be bugs in this, especially wrt. transmit
      power handling where I'm basically clueless about how it should work.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  18. 11 10月, 2007 1 次提交