Hi Denis,
Thanks for the capture file (for everyone else - Denis provided this to
Arend and myself privately).
In it, we see that there are only ever beacons with zeroed out SSID, and
probe responses with correct SSID. Nothing weird mixed.
> denkenz@iwd-test ~ $ sudo iw dev wlp2s0 scan flush
> 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
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.
johannes
