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

Hi Denis, > > 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, but you still get that info conveyed through the Beacon IEs > elements on the

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

On 05/22/2018 04:28 PM, Johannes Berg wrote: 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

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

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. >

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

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

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

On Tue, 2018-05-22 at 16:00 -0500, Denis Kenzior wrote: > > > So what's the practical use of the flush flag? Or is that something > > > that was meant to be 'for-testing-only'? > > > > I think you misunderstand? The value is that it ensures that nothing is > > present in the list that was

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

Hi Johannes, > On May 22, 2018, at 3:52 PM, Johannes Berg wrote: > > On Tue, 2018-05-22 at 15:49 -0500, Denis Kenzior wrote: > >> Okay, so we need to use NL80211_BSS_PRESP_DATA if we want to filter out >> scan results that are coming from beacons, right? > > You

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

On Tue, 2018-05-22 at 15:49 -0500, Denis Kenzior wrote: > Okay, so we need to use NL80211_BSS_PRESP_DATA if we want to filter out > scan results that are coming from beacons, right? You could do that, yes. In non-hidden cases you get the beacon/probe response data combined, in hidden cases you

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

Hi Johannes, On 05/22/2018 03:40 PM, Johannes Berg wrote: Hi, 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

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

Hi, > 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. Oh. I didn't even think about this part,

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

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

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

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 >

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

Hi Johannes, On 05/22/2018 09:51 AM, Johannes Berg wrote: On Tue, 2018-05-22 at 16:50 +0200, Johannes Berg wrote: On Tue, 2018-05-22 at 09:48 -0500, Denis Kenzior wrote: Hi Arend, Are you saying the first result is from the Beacon and the other is from the Probe Response? Then why are the

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

On Tue, 2018-05-22 at 16:50 +0200, Johannes Berg wrote: > On Tue, 2018-05-22 at 09:48 -0500, Denis Kenzior wrote: > > Hi Arend, > > > > > > 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 > > >

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

Hi Johannes, On 05/22/2018 03:12 AM, Johannes Berg wrote: Hi Denis, 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

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

On Tue, 2018-05-22 at 09:48 -0500, Denis Kenzior wrote: > Hi Arend, > > > > 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

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

Hi Arend, 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

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

Hi Denis, > 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 >

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

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

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

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

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

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

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

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

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

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

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

__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. This patch is addressing the described issue by changing the semantics of the function (__cfg80211_bss_expire) parameter from a