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

[Denis Kenzior <denkenz@gmail.com>]

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 just curious what other potential uses this flag might have.
> 
> Well, basically, ensure that your scan data is up-to-date?
> 
> I think mostly it's because there are scenarios where the AP is expected
> to vary the probe response data, so you need to know if you
>   * have a new probe response, or
>   * didn't receive a new probe response, or
>   * the AP erroneously didn't change the new probe response.

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.

Regards,
-Denis