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

[Denis Kenzior <denkenz@gmail.com>]

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