1. 11 9月, 2014 5 次提交
  2. 05 9月, 2014 3 次提交
  3. 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
  4. 21 7月, 2014 1 次提交
  5. 26 6月, 2014 1 次提交
  6. 24 6月, 2014 1 次提交
  7. 23 6月, 2014 1 次提交
  8. 26 5月, 2014 1 次提交
  9. 20 5月, 2014 2 次提交
  10. 15 5月, 2014 3 次提交
  11. 13 5月, 2014 1 次提交
  12. 29 4月, 2014 1 次提交
  13. 25 4月, 2014 4 次提交
  14. 09 4月, 2014 7 次提交
  15. 26 2月, 2014 3 次提交
  16. 21 2月, 2014 2 次提交
  17. 20 2月, 2014 1 次提交
    • S
      cfg80211: Pass TDLS peer capability information in tdls_mgmt · df942e7b
      Sunil Dutt Undekari 提交于
      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: NSunil Dutt Undekari <usdutt@qti.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      df942e7b
  18. 12 2月, 2014 1 次提交
  19. 06 2月, 2014 1 次提交
    • J
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      f9d15d16