Re: [PATCH] cfg80211: Fix support for flushing old scan results

[Denis Kenzior <denkenz@gmail.com>]

On 05/22/2018 04:28 PM, Johannes Berg wrote:
> On Tue, 2018-05-22 at 16:25 -0500, Denis Kenzior wrote:
>> Hi Johannes,
>>
>>> But in theory, I think you could've received the beacon with hidden SSID
>>> *before* the scan, yet it might be present in the scan results if the
>>> new scan caused the probe response to be associated with that scan.
>>
>> Right, your explanation was helpful, thanks.  It still seems completely
>> weird and redundant that we get two separate entries though.  The second
>> entry with the probe response data still carries the beacon info (as you
>> point out).  Should the pure-beacon one be filtered?
> 
> I'm not sure. It still indicates that a hidden SSID was found, and in
> general even a real SSID on the same BSSID doesn't indicate that this
> was the only hidden SSID ...

Right, but you still get that info conveyed through the Beacon IEs 
elements on the second/third/etc entry.  So it still seems redundant to 
include the pure beacon one?

Also, given that you have to ask for the SSID you want specifically, 
what practical purpose does it serve to know that this wasn't the only 
hidden SSID?  I mean you can see that hidden SSIDs are out there, run an 
active scan for the ones you can use.  If none are there, you can just 
ignore that bssid...

> 
>> Right, so thinking out loud here.  Would it be useful to tell GET SCAN
>> to only return entries with actual probe response data?  Combined with
>> the flush flag it seems like a much better fit for the cases you point out.
> 
> I don't really see much point in doing filtering in the kernel. It
> wouldn't doesn't hurt, but just trades off more kernel code for less
> transferred data - and that's mostly in this particular corner case, so
> not really an efficiency problem?

Fair enough.  It was more motivated by 'make the API a bit more readable 
/ accessible / user friendly'.

> 
> And if it wasn't a hidden SSID, then you probably do want to know about
> the non-hidden SSIDs that you picked up along the way. In fact, this
> will become crucial with OCE, since that results in cases where you
> don't even send a probe request if you've picked up certain things
> during the scan passively.

Right.  In our case we only scan passively unless we detect a hidden 
ssid and have provisioned hidden ssids.  Then we issue an active scan 
for just those...

Regards,
-Denis