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

[Arend van Spriel <arend.vanspriel@broadcom.com>]

On 5/18/2018 9:00 PM, Denis Kenzior wrote:
> Hi Arend,
>
> On 05/18/2018 01:54 PM, Arend van Spriel wrote:
>> On 5/18/2018 6:47 PM, Denis Kenzior wrote:
>>> Hi Johannes,
>>>
>>> On 05/18/2018 03:13 AM, Johannes Berg wrote:
>>>> On Fri, 2018-05-11 at 09:48 -0700, Tim Kourt wrote:
>>>>> __cfg80211_bss_expire function was incorrectly used to flush the BSS
>>>>> entries from the previous scan results, causing
>>>>> NL80211_SCAN_FLAG_FLUSH
>>>>> flag to have no effect.
>>>>
>>>> Hmm. I guess I'm not convinced - what's the bug?
>>>>
>>>> We flush anything that's older than our start, so that should work just
>>>> fine?
>>>>
>>>
>>> Just FYI, there's definitely something funny with the scanning code:
>>>
>>> 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
>>>
>>>
>>> Then if I try:
>>> denkenz@iwd-test ~ $ sudo iw dev wlp2s0 scan flush ssid myssid
>>> BSS 10:c3:7b:54:74:d4(on wlp2s0)
>>>      last seen: 319.667s [boottime]
>>>      freq: 5765
>>>      beacon interval: 100 TUs
>>>      signal: -42.00 dBm
>>>      last seen: 350 ms ago
>>>      Information elements from Probe Response frame:
>>>      SSID: \x00\x00\x00\x00\x00\x00\x00\x00\x00
>>> ....
>>> BSS 10:c3:7b:54:74:d4(on wlp2s0)
>>>      last seen: 319.662s [boottime]
>>>      freq: 5765
>>>      beacon interval: 100 TUs
>>>      signal: -37.00 dBm
>>>      last seen: 355 ms ago
>>>      Information elements from Probe Response frame:
>>>      SSID: myssid
>>>
>>> Shouldn't the second scan give a single result from that one BSS?
>>
>> Looking at the 'last seen' values it does look ok. Both results have
>> the same BSSID, but the first one shows the broadcast ssid (or so it
>> seems).
>
> Are you saying the first result is from the Beacon and the other is from
> the Probe Response?  Then why are the 'Information elements from Probe
> Response frame' the way they are?

Nope. I am not saying that. I am saying that there are two probe 
requests being sent. One with broadcast ssid, ie. ssid_len == 0, and 
with ssid 'myssid'. But it is speculation without a sniffer capture.

>> Neither iw nor nl80211 on the kernel side add the broadcast ssid. So
>> question is what device are you using and does it use mac80211 software
>
> Intel 7260.  We're seeing the same results with hwsim as well though.
> This was just a quick test to illustrate.

That seems to point to mac80211 although I am not very familiar with 
neither mac80211_hwsim nor iwlwifi.

>> scanning or hardware scanning. I did not dive into mac80211 to see if
>> the broadcast ssid is added there.
>
> By the way, if you're interested.  The same tests with a Broadcom based
> device wouldn't even find the hidden network.  It would always come back
> with a single 'x00' SSID regardless of whether I added 'ssid myssid' at
> the end.

Interesting. So that means firmware does not honor the ssids passed or 
brcmfmac does something wrong. Need to look into that.

Thanks,
Arend