broadcast ssid in scheduled scan

broadcast ssid in scheduled scan

[Arend van Spriel]

Johannes, Jouni,

I have noticed that under some circumstances wpa_supplicant initiates a 
scheduled scan with broadcast ssid. This is something our firmware can 
not do so could this be avoided? Maybe by adding a feature flag for it. 
I will look into it some more to understand the scenarios in which 
broadcast ssid is used in scheduled scan request. If you know about this 
feel free to let me know.

Regards,
Arend

Re: broadcast ssid in scheduled scan

[Arend van Spriel]

On 03/23/15 19:38, Arend van Spriel wrote:
> Johannes, Jouni,
>
> I have noticed that under some circumstances wpa_supplicant initiates a
> scheduled scan with broadcast ssid. This is something our firmware can
> not do so could this be avoided? Maybe by adding a feature flag for it.
> I will look into it some more to understand the scenarios in which
> broadcast ssid is used in scheduled scan request. If you know about this
> feel free to let me know.

 From the code in wpa_supplicant_req_sched_scan() it seems the wildcard 
ssid (referred to as broadcast ssid) is added if one or more networks 
are configured without 'scan_ssid=1'. So if none of the networks have 
this option only the broadcast ssid ends up in the request.

Regards,
Arend

> Regards,
> Arend
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: broadcast ssid in scheduled scan

[Johannes Berg]

On Mon, 2015-03-23 at 19:38 +0100, Arend van Spriel wrote:
> Johannes, Jouni,
> 
> I have noticed that under some circumstances wpa_supplicant initiates a 
> scheduled scan with broadcast ssid. This is something our firmware can 
> not do so could this be avoided? Maybe by adding a feature flag for it. 

I guess this would be difficult to do since you'd basically have to
"remove" support for normal scheduled scan (that assumes this ability)
and add support for another scheduled scan (that doesn't assume it) in
nl80211 ... just to be compatible with older implementations of
wpa_supplicant etc.

I do wonder why the firmware cannot do this though - there's no
fundamental reason the 0-length SSID is all that different from a 1-byte
one?

johannes

Re: broadcast ssid in scheduled scan

[Luca Coelho]

On Tue, 2015-03-31 at 16:21 +0200, Johannes Berg wrote:
> On Mon, 2015-03-23 at 19:38 +0100, Arend van Spriel wrote:
> > Johannes, Jouni,
> > 
> > I have noticed that under some circumstances wpa_supplicant initiates a 
> > scheduled scan with broadcast ssid. This is something our firmware can 
> > not do so could this be avoided? Maybe by adding a feature flag for it. 
> 
> I guess this would be difficult to do since you'd basically have to
> "remove" support for normal scheduled scan (that assumes this ability)
> and add support for another scheduled scan (that doesn't assume it) in
> nl80211 ... just to be compatible with older implementations of
> wpa_supplicant etc.
> 
> I do wonder why the firmware cannot do this though - there's no
> fundamental reason the 0-length SSID is all that different from a 1-byte
> one?

Is the problem in having a 0-length SSID in the probe_reqs or is it in
having it in the matches (i.e. it doesn't support "pass all")? The
latter makes a bit more sense, since filtering on a 0-length SSID, if
not treated specially, would return nothing (since it would never match,
unless an AP does send an SSID IE with 0-length).

It doesn't make much sense to have a "match all" scheduled scan though,
unless wpa_s needs to find more SSIDs than what the driver supports.
Even in that case, it wouldn't make much difference than using a normal
scan periodically...

--
Luca.

Re: broadcast ssid in scheduled scan

[Arend van Spriel]

On 04/01/15 08:28, Luca Coelho wrote:
> On Tue, 2015-03-31 at 16:21 +0200, Johannes Berg wrote:
>> On Mon, 2015-03-23 at 19:38 +0100, Arend van Spriel wrote:
>>> Johannes, Jouni,
>>>
>>> I have noticed that under some circumstances wpa_supplicant initiates a
>>> scheduled scan with broadcast ssid. This is something our firmware can
>>> not do so could this be avoided? Maybe by adding a feature flag for it.
>>
>> I guess this would be difficult to do since you'd basically have to
>> "remove" support for normal scheduled scan (that assumes this ability)
>> and add support for another scheduled scan (that doesn't assume it) in
>> nl80211 ... just to be compatible with older implementations of
>> wpa_supplicant etc.
>>
>> I do wonder why the firmware cannot do this though - there's no
>> fundamental reason the 0-length SSID is all that different from a 1-byte
>> one?
>
> Is the problem in having a 0-length SSID in the probe_reqs or is it in
> having it in the matches (i.e. it doesn't support "pass all")? The
> latter makes a bit more sense, since filtering on a 0-length SSID, if
> not treated specially, would return nothing (since it would never match,
> unless an AP does send an SSID IE with 0-length).

This is indeed the issue. The scheduled scan firmware implementation 
sits on top of the scan engine and tries to match found bss'es. So 
having a broadcast ssid in struct cfg80211_sched_scan_request::ssids but 
it is for struct cfg80211_sched_scan_request::match_sets.

> It doesn't make much sense to have a "match all" scheduled scan though,
> unless wpa_s needs to find more SSIDs than what the driver supports.
> Even in that case, it wouldn't make much difference than using a normal
> scan periodically...

That is what scheduled scan with only broadcast ssid intends to do, 
right? I guess the advantage is that host can be idle.

Regards,
Arend

> --
> Luca.
>