broadcast ssid in scheduled scan
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
Quoted 8 lines · Arend van Spriel
Johannes, Jouni,
I have noticed that under some circumstances
wpa_supplicantinitiates 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
Quoted 7 lines
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Arend van Spriel
Johannes, Jouni,
I have noticed that under some circumstances
wpa_supplicantinitiates 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
Quoted 13 lines · Johannes Berg
Quoted 5 lines · Arend van Spriel
Johannes, Jouni,
I have noticed that under some circumstances
wpa_supplicantinitiates 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_supplicantetc.
Quoted 3 lines
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.
Quoted 18 lines · Luca Coelho
Quoted 13 lines · Johannes Berg
Quoted 5 lines · Arend van Spriel
Johannes, Jouni,
I have noticed that under some circumstances
wpa_supplicantinitiates 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_supplicantetc.Quoted 3 lines
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?
Quoted 5 lines
Is the problem in having a 0-length SSID in the
probe_reqsor 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.
Quoted 4 lines
It doesn't make much sense to have a "match all" scheduled scan though, unless
wpa_sneeds 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
Quoted 3 lines
--
Luca.