1. 05 Sep, 2014 2 commits
  2. 26 Aug, 2014 1 commit
    • Johannes Berg's avatar
      cfg80211: clarify BSS probe response vs. beacon data · 0e227084
      Johannes Berg authored
      
      
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      0e227084
  3. 21 Jul, 2014 1 commit
  4. 25 Jun, 2014 1 commit
  5. 24 Jun, 2014 1 commit
  6. 23 Jun, 2014 1 commit
  7. 26 May, 2014 1 commit
  8. 20 May, 2014 1 commit
  9. 19 May, 2014 1 commit
  10. 15 May, 2014 3 commits
  11. 13 May, 2014 1 commit
  12. 28 Apr, 2014 1 commit
  13. 25 Apr, 2014 4 commits
  14. 09 Apr, 2014 7 commits
  15. 25 Feb, 2014 3 commits
  16. 21 Feb, 2014 2 commits
  17. 20 Feb, 2014 1 commit
    • Sunil Dutt Undekari's avatar
      cfg80211: Pass TDLS peer capability information in tdls_mgmt · df942e7b
      Sunil Dutt Undekari authored
      
      
      While framing the TDLS Setup Confirmation frame, the driver needs to
      know if the TDLS peer is VHT/HT/WMM capable and thus shall construct
      the VHT/HT operation / WMM parameter elements accordingly. Supplicant
      determines if the TDLS peer is VHT/HT/WMM capable based on the
      presence of the respective IEs in the received TDLS Setup Response frame.
      
      The host driver should not need to parse the received TDLS Response
      frame and thus, should be able to rely on the supplicant to indicate
      the capability of the peer through additional flags while transmitting
      the TDLS Setup Confirmation frame through tdls_mgmt operations.
      Signed-off-by: default avatarSunil Dutt Undekari <usdutt@qti.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      df942e7b
  18. 12 Feb, 2014 1 commit
  19. 06 Feb, 2014 2 commits
    • Johannes Berg's avatar
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg authored
      
      
      Due to the previous commit, when a scan finishes, it is in theory
      possible to hit the following sequence:
       1. interface starts being removed
       2. scan is cancelled by driver and cfg80211 is notified
       3. scan done work is scheduled
       4. interface is removed completely, rdev->scan_req is freed,
          event sent to userspace but scan done work remains pending
       5. new scan is requested on another virtual interface
       6. scan done work runs, freeing the still-running scan
      
      To fix this situation, hang on to the scan done message and block
      new scans while that is the case, and only send the message from
      the work function, regardless of whether the scan_req is already
      freed from interface removal. This makes step 5 above impossible
      and changes step 6 to be
       5. scan done work runs, sending the scan done message
      
      As this can't work for wext, so we send the message immediately,
      but this shouldn't be an issue since we still return -EBUSY.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9d15d16
    • Pontus Fuchs's avatar
      nl80211: Reset split_start when netlink skb is exhausted · f12cb289
      Pontus Fuchs authored
      When the netlink skb is exhausted split_start is left set. In the
      subsequent retry, with a larger buffer, the dump is continued from the
      failing point instead of from the beginning.
      
      This was causing my rt28xx based USB dongle to now show up when
      running "iw list" with an old iw version without split dump support.
      
      Cc: stable@vger.kernel.org
      Fixes: 3713b4e3
      
       ("nl80211: allow splitting wiphy information in dumps")
      Signed-off-by: default avatarPontus Fuchs <pontus.fuchs@gmail.com>
      [avoid the entire workaround when state->split is set]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f12cb289
  20. 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
  21. 04 Feb, 2014 4 commits
    • Michal Kazior's avatar
      cfg80211: consider existing DFS interfaces · 9e0e2961
      Michal Kazior authored
      
      
      It was possible to break interface combinations in
      the following way:
      
       combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
       combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20
      
      With the above interface combinations it was
      possible to:
      
       step 1. start AP on DFS channel by matching combo 2
       step 2. start AP on non-DFS channel by matching combo 1
      
      This was possible beacuse (step 2) did not consider
      if other interfaces require radar detection.
      
      The patch changes how cfg80211 tracks channels -
      instead of channel itself now a complete chandef
      is stored.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9e0e2961
    • Janusz Dziedzic's avatar
      cfg80211: set preset_chandef after channel switch · 96f55f12
      Janusz Dziedzic authored
      
      
      Set preset_chandef in channel switch notification.
      In other case we will have old preset_chandef.
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      96f55f12
    • Johannes Berg's avatar
      nl80211: fix scheduled scan RSSI matchset attribute confusion · ea73cbce
      Johannes Berg authored
      
      
      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: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Acked-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ea73cbce
    • Johannes Berg's avatar
      nl80211: send event when AP operation is stopped · 348baf0e
      Johannes Berg authored
      
      
      There are a few cases, e.g. suspend, where an AP interface is
      stopped by the kernel rather than by userspace request, most
      commonly when suspending. To let userspace know about this,
      send the NL80211_CMD_STOP_AP command as an event every time
      an AP interface is stopped. This also happens when userspace
      did in fact request the AP stop, but that's not a problem.
      
      For full-MAC drivers this may need to be extended to also
      cover cases where the device stopped the AP operation for
      some reason, this a bit more complicated because then all
      cfg80211 state also needs to be reset; such API is not part
      of this patch.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      348baf0e