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
