How to handle multiple SSIDs with the same BSS

[Witold Sowa]

Marcel Holtmann pisze:
> Hi Witold,
> 
>>>>> BSS 00:1a:a1:53:50:a0 (on wlan0)
>>>>> 	SSID: Private
>>>>> BSS 00:1a:a1:53:50:a0 (on wlan0)
>>>>> 	SSID: Public
>>>>> When using the wpa_supplicant D-Bus interface, every BSS can only be
>>>>> listed once and so we either see "Private" or "Public", but never
>>>>> actually both of them. How should this be handled.
>>>> I wasn't aware that there is this kind of limitation in the D-Bus
>>>> interface. It is clearly broken if it cannot include both of those
>>>> networks.
>>> from what I have read so far while going through the code, it is not
>>> possible. The BSSID is used as unique path in D-Bus terms and because of
>>> that there is no way both networks could be listed at the same time.
>>>
>> Precisely. Path of DBus object representing BSS is based on BSSID. Since
>> the path must be unique we can't have both networks listed.
>> I think that we can change a path format quite easy in the new DBus API,
>> but I'm afraid that changes in the old API may may brake it.
>> Actually, I was sure that BSSID is an unique identifier, but obviously
>> we need to think out something else. Is the pair of BSSID and SSID
>> unique? I'm not sure.
> 
> I think that BSSID + SSID should be enough. At least for now and we
> could always make it more complicated later. Since it is only a string
> in the end. And you should discover this string via D-Bus in the first
> place and not guess it.
> 
The problem is that the BSSID should be uniquely identify a BSS - by
design. Since it isn't in practice, we may never be sure that we can
distinguish two scan results basic on the result itself. Actually, I can
imagine a situation when the AP broadcasts two the same SSIDs from the
same BSS but with different security settings. Furthermore, I can
imagine broadcasting two the same SSIDs from the same BSS and with the
same IEs and capabilities but then it would be impossible to distinguish
SSIDs and it would actually become a single SSID.
Nevertheless I think that the (BSSID,SSID) pair would cover most of the
cases.

> Since the SSID is a byte array, I would propose to convert the SSID into
> a hex string representation and just append it to hex string you use for
> the BSSID. This way we can support non-ASCII SSID and more important
> don't have to do weird escaping because a D-Bus object path charset is
> limited.
> 
I agree.

>>>>> Also looking into the register_bss callbacks, you only get the BSS
>>>>> address and not the set of IE.
>>>> I don't know how this mechanism is supposed to be used, but there needs
>>>> to be a way for fetching more information about the BSS and BSSID by
>>>> itself is not a sufficient key for identifying which BSS is being
>>>> queried for (need to have BSSID,SSID pair or some other internally
>>>> generated identifier which can be guaranteed to be unique).
>>> Does wpa_supplicant already generate such unique BSS based identifier
>>> somewhere internally? If not, it might make sense to do so.
>> It doesn't AFAIK. We generate identifier for DBus usage only.
> 
> I still think we should add a generic function for this. It should
> either generate a unique string and unique byte array for each BSS.
> 
Yes, something like
char * generate_bss_unique_id(const struct wpa_scan_res *res)
would be useful.

Witek.