1. 07 Dec, 2015 1 commit
    • Ilan Peer's avatar
      mac80211: handle HW ROC expired properly · 1b894521
      Ilan Peer authored
      In case of HW ROC, when the driver reports that the ROC expired,
      it is not sufficient to purge the ROCs based on the remaining
      time, as it possible that the device finished the ROC session
      before the actual requested duration.
      
      To handle such cases, in case of ROC expired notification from
      the driver, complete all the ROCs which are marked with hw_begun,
      regardless of the remaining duration.
      Signed-off-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1b894521
  2. 04 Dec, 2015 37 commits
  3. 02 Dec, 2015 2 commits
    • Johannes Berg's avatar
      mac80211: fix off-channel mgmt-tx uninitialized variable usage · c1df932c
      Johannes Berg authored
      In the last change here, I neglected to update the cookie in one code
      path: when a mgmt-tx has no real cookie sent to userspace as it doesn't
      wait for a response, but is off-channel. The original code used the SKB
      pointer as the cookie and always assigned the cookie to the TX SKB in
      ieee80211_start_roc_work(), but my change turned this around and made
      the code rely on a valid cookie being passed in.
      
      Unfortunately, the off-channel no-wait TX path wasn't assigning one at
      all, resulting in an uninitialized stack value being used. This wasn't
      handed back to userspace as a cookie (since in the no-wait case there
      isn't a cookie), but it was tested for non-zero to distinguish between
      mgmt-tx and off-channel.
      
      Fix this by assigning a dummy non-zero cookie unconditionally, and get
      rid of a misleading comment and some dead code while at it. I'll clean
      up the ACK SKB handling separately later.
      
      Fixes: 3b79af97 ("mac80211: stop using pointers as userspace cookies")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c1df932c
    • Antonio Quartulli's avatar
      mac80211: do not actively scan DFS channels · 4e39ccac
      Antonio Quartulli authored
      DFS channels should not be actively scanned as we can't be sure
      if we are allowed or not.
      
      If the current channel is in the DFS band, active scan might be
      performed after CSA, but we have no guarantee about other channels,
      therefore it is safer to prevent active scanning at all.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4e39ccac