1. 06 Mar, 2015 1 commit
    • Ilan peer's avatar
      cfg80211: Add API to change the indoor regulatory setting · 05050753
      Ilan peer authored
      Previously, the indoor setting configuration assumed that as
      long as a station interface is connected, the indoor environment
      setting does not change. However, this assumption is problematic
      as:
      
      - It is possible that a station interface is connected to a mobile
        AP, e.g., softAP or a P2P GO, where it is possible that both the
        station and the mobile AP move out of the indoor environment making
        the indoor setting invalid. In such a case, user space has no way to
        invalidate the setting.
      - A station interface disconnection does not necessarily imply that
        the device is no longer operating in an indoor environment, e.g.,
        it is possible that the station interface is roaming but is still
        stays indoor.
      
      To handle the above, extend the indoor configuration API to allow
      user space to indicate a change of indoor settings, and allow it to
      indicate weather it controls the indoor setting, such that:
      
      1. If the user space process explicitly indicates that it is going
         to control the indoor setting, do not clear the indoor setting
         internally, unless the socket is released. The user space process
         should use the NL80211_ATTR_SOCKET_OWNER attribute in the command
         to state that it is going to control the indoor setting.
      2. Reset the indoor setting when restoring the regulatory settings in
         case it is not owned by a user space process.
      
      Based on the above, a user space tool that continuously monitors the
      indoor settings, i.e., tracking power setting, location etc., can
      indicate environment changes to the regulatory core.
      
      It should be noted that currently user space is the only provided mechanism
      used to hint to the regulatory core over the indoor/outdoor environment --
      while the country IEs do have an environment setting this has been completely
      ignored by the regulatory core by design for a while now since country IEs
      typically can contain bogus data.
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarArikX Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      05050753
  2. 17 Dec, 2014 1 commit
  3. 09 Apr, 2014 3 commits
  4. 25 Feb, 2014 1 commit
  5. 05 Feb, 2014 1 commit
    • Janusz Dziedzic's avatar
      cfg80211: regulatory introduce maximum bandwidth calculation · 97524820
      Janusz Dziedzic authored
      In case we will get regulatory request with rule
      where max_bandwidth_khz is set to 0 handle this
      case as a special one.
      
      If max_bandwidth_khz == 0 we should calculate maximum
      available bandwidth base on all frequency contiguous rules.
      In case we need auto calculation we just have to set:
      
      country PL: DFS-ETSI
              (2402 - 2482 @ 40), (N/A, 20)
              (5170 - 5250 @ AUTO), (N/A, 20)
              (5250 - 5330 @ AUTO), (N/A, 20), DFS
              (5490 - 5710 @ 80), (N/A, 27), DFS
      
      This mean we will calculate maximum bw for rules where
      AUTO (N/A) were set, 160MHz (5330 - 5170) in example above.
      So we will get:
              (5170 - 5250 @ 160), (N/A, 20)
              (5250 - 5330 @ 160), (N/A, 20), DFS
      
      In other case:
      country FR: DFS-ETSI
              (2402 - 2482 @ 40), (N/A, 20)
              (5170 - 5250 @ AUTO), (N/A, 20)
              (5250 - 5330 @ 80), (N/A, 20), DFS
              (5490 - 5710 @ 80), (N/A, 27), DFS
      
      We will get 80MHz (5250 - 5170):
              (5170 - 5250 @ 80), (N/A, 20)
              (5250 - 5330 @ 80), (N/A, 20), DFS
      
      Base on this calculations we will set correct channel
      bandwidth flags (eg. IEEE80211_CHAN_NO_80MHZ).
      
      We don't need any changes in CRDA or internal regulatory.
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      [extend nl80211 description a bit, fix typo]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      97524820
  6. 03 Dec, 2013 1 commit
  7. 25 Nov, 2013 2 commits
  8. 09 Oct, 2013 1 commit
  9. 03 Jan, 2013 3 commits
  10. 30 Nov, 2012 1 commit
    • Johannes Berg's avatar
      cfg80211: fix BSS struct IE access races · 9caf0364
      Johannes Berg authored
      When a BSS struct is updated, the IEs are currently
      overwritten or freed. This can lead to races if some
      other CPU is accessing the BSS struct and using the
      IEs concurrently.
      
      Fix this by always allocating the IEs in a new struct
      that holds the data and length and protecting access
      to this new struct with RCU.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9caf0364
  11. 17 Jul, 2012 3 commits
  12. 04 Jan, 2012 1 commit
  13. 21 Nov, 2011 1 commit
  14. 14 Sep, 2011 1 commit
  15. 09 Mar, 2011 1 commit
  16. 18 Jun, 2010 1 commit
  17. 01 Feb, 2010 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: add regulatory hint disconnect support · 09d989d1
      Luis R. Rodriguez authored
      This adds a new regulatory hint to be used when we know all
      devices have been disconnected and idle. This can happen
      when we suspend, for instance. When we disconnect we can
      no longer assume the same regulatory rules learned from
      a country IE or beacon hints are applicable so restore
      regulatory settings to an initial state.
      
      Since driver hints are cached on the wiphy that called
      the hint, those hints are not reproduced onto cfg80211
      as the wiphy will respect its own wiphy->regd regardless.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      09d989d1
  18. 15 Jan, 2010 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: make regulatory_hint_11d() band specific · 84920e3e
      Luis R. Rodriguez authored
      In practice APs do not send country IE channel triplets for channels
      the AP is not operating on and if they were to do so they would have
      to use the regulatory extension which we currently do not process.
      No AP has been seen in practice that does this though so just drop
      those country IEs.
      
      Additionally it has been noted the first series of country IE
      channels triplets are specific to the band the AP sends. Propagate
      the band on which the country IE was found on reject the country
      IE then if the triplets are ever oustide of the band.
      
      Although we now won't process country IE information with multiple
      band information we leave the intersection work as is as it is
      technically possible for someone to want to eventually process these
      type of country IEs with regulatory extensions.
      
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      84920e3e
  19. 04 Aug, 2009 1 commit
  20. 03 Aug, 2009 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: fix regression on beacon world roaming feature · 37184244
      Luis R. Rodriguez authored
      A regression was added through patch a4ed90d6:
      
      "cfg80211: respect API on orig_flags on channel for beacon hint"
      
      We did indeed respect _orig flags but the intention was not clearly
      stated in the commit log. This patch fixes firmware issues picked
      up by iwlwifi when we lift passive scan of beaconing restrictions
      on channels its EEPROM has been configured to always enable.
      
      By doing so though we also disallowed beacon hints on devices
      registering their wiphy with custom world regulatory domains
      enabled, this happens to be currently ath5k, ath9k and ar9170.
      The passive scan and beacon restrictions on those devices would
      never be lifted even if we did find a beacon and the hardware did
      support such enhancements when world roaming.
      
      Since Johannes indicates iwlwifi firmware cannot be changed to
      allow beacon hinting we set up a flag now to specifically allow
      drivers to disable beacon hints for devices which cannot use them.
      
      We enable the flag on iwlwifi to disable beacon hints and by default
      enable it for all other drivers. It should be noted beacon hints lift
      passive scan flags and beacon restrictions when we receive a beacon from
      an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
      band. We don't bother with channels 1-11 as those channels are allowed
      world wide.
      
      This should fix world roaming for ath5k, ath9k and ar9170, thereby
      improving scan time when we receive the first beacon from any AP,
      and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
      would otherwise not be allowed to do so. Drivers not using custom
      regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
      by this as the orig_flags for the channels would have been cleared
      upon wiphy registration.
      
      I tested this with a world roaming ath5k card.
      
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      37184244
  21. 27 Feb, 2009 3 commits
  22. 09 Feb, 2009 1 commit
  23. 29 Jan, 2009 1 commit
  24. 25 Nov, 2008 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211/mac80211: Add 802.11d support · 3f2355cb
      Luis R. Rodriguez authored
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3f2355cb
  25. 31 Oct, 2008 3 commits
  26. 24 Sep, 2008 2 commits
  27. 15 Sep, 2008 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: Add new wireless regulatory infrastructure · b2e1b302
      Luis R. Rodriguez authored
      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: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b2e1b302