Hi Johannes,
I think I finally figured out what's going on. It's a mix between
strange 'iw' behaviour, and strange backward-compatibility behaviour in
cfg80211.
If you do this again and give the scan dump command explicitly with -b
added, like
sudo iw dev wlp2s0 scan passive
iw dev wlp2s0 scan dump -b
then you'll likely see
BSS 10:c3:7b:54:74:d4(on wlp2s0)
last seen: 274.815s [boottime]
freq: 5765
beacon interval: 100 TUs
signal: -35.00 dBm
last seen: 349 ms ago
Information elements from Probe Response frame:
SSID: \x00\x00\x00\x00\x00\x00\x00\x00\x00
[... ht/vht ...]
Information elements from Beacon frame:
SSID: \x00\x00\x00\x00\x00\x00\x00\x00\x00
[... ht/vht ...]
So there are two things going on:
1) In iw, we limit the amount of information printed, but in that case
still print "Information elements from Probe Response frame", if beacon
IEs are also present in the BSS information.
2) Originally, the kernel didn't distinguish between probe response and
beacon IE attributes, but only had "IEs" in general. When we later did
want to distinguish, we changed nl80211 to unconditionally put some IEs
into the "IEs", if received from beacon put them into "beacon IEs", but
to avoid further duplication didn't introduce a separate "probe response
IEs" attribute. You can see this in nl80211_send_bss():
/* this pointer prefers to be pointed to probe response data
* but is always valid
*/
ies = rcu_dereference(res->ies);
if (ies) {
if (nla_put_u64_64bit(msg, NL80211_BSS_TSF, ies->tsf,
NL80211_BSS_PAD))
goto fail_unlock_rcu;
if (ies->len && nla_put(msg, NL80211_BSS_INFORMATION_ELEMENTS,
ies->len, ies->data))
goto fail_unlock_rcu;
}
/* and this pointer is always (unless driver didn't know) beacon data */
ies = rcu_dereference(res->beacon_ies);
if (ies && ies->from_beacon) {
if (nla_put_u64_64bit(msg, NL80211_BSS_BEACON_TSF, ies->tsf,
NL80211_BSS_PAD))
goto fail_unlock_rcu;
if (ies->len && nla_put(msg, NL80211_BSS_BEACON_IES,
ies->len, ies->data))
goto fail_unlock_rcu;
}
Ultimately, this is also lossy - so later I added NL80211_BSS_PRESP_DATA
that indicates "these were *really* received by probe response.
I guess I should change iw in the following way:
https://p.sipsolutions.net/6958d16d00f955c7.txt
which will mean it will not print "probe response IEs" in a false
positive way.
Obviously on kernels that don't set NL80211_BSS_PRESP_DATA it won't
print it out even if the beacon/probe response were both received with
different content, but it can't know if the kernel doesn't tell it.
So I need to absorb all of this some more, but I'm still wondering why
we are seeing two separate scan entries (with hidden & plain ssid) when
we requested a flush? Is there a way to force the kernel to only show
us the probe responses.
It would seem that even with the flush flag set, there could still be
spurious beacons getting in causing these results to appear in the scan
result set, right?
Regards,
-Denis
