How to handle multiple SSIDs with the same BSS

[Dan Williams]

On Wed, 2009-12-23 at 21:14 +0200, Jouni Malinen wrote:
> On Wed, Dec 23, 2009 at 04:48:11AM -0800, Marcel Holtmann wrote:
> 
> > 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.

Not a limitation of D-Bus at all, but a limitation of how I decided to
do object paths of the BSSIDs 3 years ago.  Object paths are
intentionally opaque, and thus we can change them at will.

The only issue is mapping the object path to a specific BSSID object in
the supplicant easily, without creating a mapping table of
path::(ssid,bssid) internally and having to do two lookups to get the
BSSID object.  Which is why I used bssid as part of the objec tpath
originally.

The main issue is that the supplicant doesn't really provide a cached
scan list at all, so the APs are somewhat transient.

What we *could* do is make more extensive use of dicts and get rid of
the .BSSID interface completely; signals send out all the details of the
scan list (including all details for each BSSID/SSID tuple) as an array
of dicts, and then have one method for retrieving the scan list.

Or, we could keep the D-Bus interface and create an internal mapping of
object path::(ssid,bssid) tuple and when we get a request for BSSID
information search the scan list for a matching (ssid,bssid) and return
info from that.

Thoughts?

Dan

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