Re: broadcast ssid in scheduled scan

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

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