[PATCH 2/2] ath10k: support MAC address randomization in scan
Arend van Spriel
arend.vanspriel at broadcom.com
Wed Apr 18 01:29:36 PDT 2018
+ Johannes (to confirm/correct my understanding regarding "supported
On 4/18/2018 4:35 AM, Dan Williams wrote:
> On Tue, 2018-04-17 at 15:26 -0700, Brian Norris wrote:
>> On Tue, Apr 17, 2018 at 2:49 PM, Arend van Spriel
>> <arend.vanspriel at broadcom.com> wrote:
>>> On 4/17/2018 6:07 PM, Brian Norris wrote:
>>>> On Tue, Apr 17, 2018 at 10:22:13AM +0200, Arend van Spriel wrote:
>>>>> 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
>>> 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.
>> I see what you're saying (though your comparison doesn't seem that
>> fair either; private ioctls are nothing like a well-defined nl80211
>> support list), and I'm totally good on looking at the new flag
>> eventually. But you still haven't answered my question ("why not?").
>> Is there a problem with the "supported commands" list?
My understanding is that in general the "supported commands" list is not
well-maintained. Not every nl80211 command is represented in the list so
user-space can not know whether it is missing or not supported.
For this particular START_SCHED_SCAN command it can be used still and
indeed probably for a long time. I just wanted to point out that it is
not recommended for new user-space functionality.
>>> The START_SCHED_SCAN command is indeed still provided to user-
>> And as I see it, it probably needs to be for essentially forever. Or
>> at least a significant amount of time after wpa_supplicant stops
>> relying on it. (Hint: it's still using it today, with no reference to
>> NL80211_ATTR_SCHED_SCAN_MAX_REQS.) There's a reason the kernel has
>> guarantees. I suspect you only get a chance to rewrite the world
>> -> nl80211) a few times in the life of kernel ABIs.
> It sometimes feels like wpa_supplicant gets treated as a static entity
> that can never be changed. In fact, send a patch to Jouni implementing
> the best practice, with a fallback to preserve compat for old kernels,
> and I'm sure he'd entertain it. Just because the supplicant does
> something a certain way, doesn't mean it's the *best* way, but it too
I was actually considering to do that. The netlink messages are easily
checked for presence of an attribute so deciding on whether to use the
fallback is trivial.
More information about the ath10k