On Tue, 2018-05-22 at 16:25 -0500, Denis Kenzior wrote: > 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 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, 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. I don't really see much point in doing filtering in the kernel. It wouldn't doesn't hurt, but just trades off more kernel code for less transferred data - and that's mostly in this particular corner case, so not really an efficiency problem? And if it wasn't a hidden SSID, then you probably do want to know about the non-hidden SSIDs that you picked up along the way. In fact, this will become crucial with OCE, since that results in cases where you don't even send a probe request if you've picked up certain things during the scan passively. johannes
