On Tue, 2018-05-22 at 16:00 -0500, Denis Kenzior wrote: > > > So what's the practical use of the flush flag? Or is that something > > > that was meant to be 'for-testing-only'? > > > > I think you misunderstand? The value is that it ensures that nothing is > > present in the list that was received *before* the scan. > > > > We misunderstood how it was supposed to work, but no, I get how things > work now. FWIW, even what I said above was slightly lying I think (though I'd have to go check the code). That's actually what I thought had happened before, though the timestamps should've allowed you to realize this, and it wasn't the case here afaict. 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. > 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. johannes
