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
