[PATCH 2/2] ath10k: support MAC address randomization in scan
Arend van Spriel
arend.vanspriel at broadcom.com
Tue Apr 17 14:49:13 PDT 2018
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
- if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN)
+ if (rdev->wiphy.max_sched_scan_reqs)
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.
More information about the ath10k