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

[Johannes Berg <johannes@sipsolutions.net>]

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, 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?

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.

johannes