1. 17 12月, 2014 2 次提交
    • J
      cfg80211: allow wiphy specific regdomain management · b0d7aa59
      Jonathan Doron 提交于
      Add a new regulatory flag that allows a driver to manage regdomain
      changes/updates for its own wiphy.
      A self-managed wiphys only employs regulatory information obtained from
      the FW and driver and does not use other cfg80211 sources like
      beacon-hints, country-code IEs and hints from other devices on the same
      system. Conversely, a self-managed wiphy does not share its regulatory
      hints with other devices in the system. If a system contains several
      devices, one or more of which are self-managed, there might be
      contradictory regulatory settings between them. Usage of flag is
      generally discouraged. Only use it if the FW/driver is incompatible
      with non-locally originated hints.
      
      A new API lets the driver send a complete regdomain, to be applied on
      its wiphy only.
      
      After a wiphy-specific regdomain change takes place, usermode will get
      a new type of change notification. The regulatory core also takes care
      enforce regulatory restrictions, in case some interfaces are on
      forbidden channels.
      Signed-off-by: NJonathan Doron <jonathanx.doron@intel.com>
      Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
      Reviewed-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b0d7aa59
    • A
      cfg80211: allow usermode to query wiphy specific regdom · ad30ca2c
      Arik Nemtsov 提交于
      If a wiphy-idx is specified, the kernel will return the wiphy specific
      regdomain, if such exists. Otherwise return the global regdom.
      
      When no wiphy-idx is specified, return the global regdomain as well as
      all wiphy-specific regulatory domains in the system, via a new nested
      list of attributes.
      
      Add a new attribute for each wiphy-specific regdomain, for usermode to
      identify it as such.
      Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ad30ca2c
  2. 27 11月, 2014 1 次提交
  3. 20 11月, 2014 5 次提交
  4. 10 11月, 2014 3 次提交
  5. 04 11月, 2014 1 次提交
    • R
      cfg80211: 802.11p OCB mode handling · 6e0bd6c3
      Rostislav Lisovy 提交于
      This patch adds new iface type (NL80211_IFTYPE_OCB) representing
      the OCB (Outside the Context of a BSS) mode.
      When establishing a connection to the network a cfg80211_join_ocb
      function is called (particular nl80211_command is added as well).
      A mandatory parameters during the ocb_join operation are 'center
      frequency' and 'channel width (5/10 MHz)'.
      
      Changes done in mac80211 are minimal possible required to avoid
      many warnings (warning: enumeration value 'NL80211_IFTYPE_OCB'
      not handled in switch) during compilation. Full functionality
      (where needed) is added in the following patch.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e0bd6c3
  6. 27 10月, 2014 1 次提交
  7. 22 10月, 2014 1 次提交
    • J
      cfg80211: make WMM TSPEC support flag an nl80211 feature flag · 723e73ac
      Johannes Berg 提交于
      During the review of the corresponding wpa_supplicant patches we
      noticed that the only way for it to detect that this functionality
      is supported currently is to check for the command support. This
      can be misleading though, as the command was also designed to, in
      the future, support pure 802.11 TSPECs.
      
      Expose the WMM-TSPEC feature flag to nl80211 so later we can also
      expose an 802.11-TSPEC feature flag (if needed) to differentiate
      the two cases.
      
      Note: this change isn't needed in 3.18 as there's no driver there
      yet that supports the functionality at all.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      723e73ac
  8. 20 10月, 2014 1 次提交
  9. 09 10月, 2014 1 次提交
  10. 11 9月, 2014 2 次提交
  11. 05 9月, 2014 3 次提交
  12. 26 8月, 2014 1 次提交
    • J
      cfg80211: clarify BSS probe response vs. beacon data · 0e227084
      Johannes Berg 提交于
      There are a few possible cases of where BSS data came from:
       1) only a beacon has been received
       2) only a probe response has been received
       3) the driver didn't report what it received (this happens when
          using cfg80211_inform_bss[_width]())
       4) both probe response and beacon data has been received
      
      Unfortunately, in the userspace API, a few things weren't there:
       a) there was no way to differentiate cases 1) and 4) above
          without comparing the data of the IEs
       b) the TSF was always from the last frame, instead of being
          exposed for beacon/probe response separately like IEs
      
      Fix this by
         i) exporting a new flag attribute that indicates whether or
            not probe response data has been received - this addresses (a)
        ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
            if a beacon has been received
       iii) not exporting the beacon attributes in case (3) above as that
            would just lead userspace into thinking the data actually came
            from a beacon when that isn't clear
      
      To implement this, track inside the IEs struct whether or not it
      (definitely) came from a beacon.
      
      Reported-by: William Seto
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0e227084
  13. 23 6月, 2014 1 次提交
  14. 20 5月, 2014 1 次提交
  15. 15 5月, 2014 2 次提交
  16. 13 5月, 2014 2 次提交
  17. 29 4月, 2014 1 次提交
  18. 25 4月, 2014 1 次提交
    • R
      cfg80211: Add attributes describing prohibited channel bandwidth · ea077c1c
      Rostislav Lisovy 提交于
      Since there are frequency bands (e.g. 5.9GHz) allowing channels
      with only 10 or 5 MHz bandwidth, this patch adds attributes that
      allow keeping track about this information.
      
      When channel attributes are reported to user-space, make sure to
      not break old tools, i.e. if the 'split wiphy dump' is enabled,
      report the extra attributes (if present) describing the bandwidth
      restrictions.  If the 'split wiphy dump' is not enabled,
      completely omit those channels that have flags set to either
      IEEE80211_CHAN_NO_10MHZ or IEEE80211_CHAN_NO_20MHZ.
      
      Add the check for new bandwidth restriction flags in
      cfg80211_chandef_usable() to comply with the restrictions.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ea077c1c
  19. 09 4月, 2014 3 次提交
  20. 26 2月, 2014 1 次提交
  21. 21 2月, 2014 1 次提交
  22. 20 2月, 2014 2 次提交
  23. 12 2月, 2014 1 次提交
  24. 05 2月, 2014 2 次提交
    • J
      cfg80211: regulatory introduce maximum bandwidth calculation · 97524820
      Janusz Dziedzic 提交于
      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: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      [extend nl80211 description a bit, fix typo]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      97524820
    • J
      nl80211: fix scheduled scan RSSI matchset attribute confusion · ea73cbce
      Johannes Berg 提交于
      The scheduled scan matchsets were intended to be a list of filters,
      with the found BSS having to pass at least one of them to be passed
      to the host. When the RSSI attribute was added, however, this was
      broken and currently wpa_supplicant adds that attribute in its own
      matchset; however, it doesn't intend that to mean that anything
      that passes the RSSI filter should be passed to the host, instead
      it wants it to mean that everything needs to also have higher RSSI.
      
      This is semantically problematic because we have a list of filters
      like [ SSID1, SSID2, SSID3, RSSI ] with no real indication which
      one should be OR'ed and which one AND'ed.
      
      To fix this, move the RSSI filter attribute into each matchset. As
      we need to stay backward compatible, treat a matchset with only the
      RSSI attribute as a "default RSSI filter" for all other matchsets,
      but only if there are other matchsets (an RSSI-only matchset by
      itself is still desirable.)
      
      To make driver implementation easier, keep a global min_rssi_thold
      for the entire request as well. The only affected driver is ath6kl.
      
      I found this when I looked into the code after Raja Mani submitted
      a patch fixing the n_match_sets calculation to disregard the RSSI,
      but that patch didn't address the semantic issue.
      Reported-by: NRaja Mani <rmani@qti.qualcomm.com>
      Acked-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ea73cbce