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

[Johannes Berg <johannes@sipsolutions.net>]

Hi Denis,

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

Yeah, it's redundant to some extent. If you're an older application not
looking at BEACON_IES attribute though, you don't see the extra beacon
data in the scan result for the hidden network that had a probe response
received.

Internally, we have to create two different BSS entries so that we can
track the BSSID/channel -> IEs mapping in one, and the potentially
multiple probe responses with different IEs in the other entries. We
ignore that relationship when sending things to userspace, but the
multiple entries are there.

> 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...

It's really just the same code though, so we'd have to have extra code
to filter if it has children, and perhaps if the client said it
understood beacon IEs or something like that ... doesn't seem worth it
to save an extra entry being sent to userspace in the (hopefully rare)
case of hidden SSID.
johannes