On 4/17/2018 6:07 PM, Brian Norris wrote:
On Tue, Apr 17, 2018 at 10:22:13AM +0200, Arend van Spriel wrote:
On 4/17/2018 2:28 AM, Brian Norris wrote:
It looks like the status quo for looking for SCHED_SCAN support is to
check if NL80211_CMD_START_SCHED_SCAN shows up in the command support
list. (IOW, that's what wpa_supplicant does.) We'll probably need to
imitate that.
I believe checking command support is not really recommended. Instead, you
better check NL80211_ATTR_SCHED_SCAN_MAX_REQS being non-zero (since kernel
4.12 that is).
Why not? Command support checking is what wpa_supplicant is doing.
That's not really a good argument. A couple (or more) years ago
wpa_supplicant was not doing nl80211 but wext and some other using
driver private ioctls, but that did not make it the best approach.
The START_SCHED_SCAN command is indeed still provided to user-space:
@@ -1376,7 +1377,7 @@ static int nl80211_add_commands_unsplit(struct
cfg80211_r
CMD(tdls_mgmt, TDLS_MGMT);
CMD(tdls_oper, TDLS_OPER);
}
- if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN)
+ if (rdev->wiphy.max_sched_scan_reqs)
CMD(sched_scan_start, START_SCHED_SCAN);
CMD(probe_client, PROBE_CLIENT);
CMD(set_noack_map, SET_NOACK_MAP);
It was left in because existing user-space apps might depend on it.
I noticed NL80211_ATTR_SCHED_SCAN_MAX_REQS, but unfortunately, we have
to support older kernels. It looks like randomization was added in
v3.19, and as you point out, that's only available in v4.12.
I figured that would be the issue so I dug up the kernel version.
I welcome other alternatives if you have them to offer.
Nope. Not if you want to be kernel version agnostic.
Regards,
Arend
