How to handle multiple SSIDs with the same BSS

[Marcel Holtmann]

Hi Dan,

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

the new D-Bus API with the BSSAdded and BSSRemoved signals that
internally cache the scan results for you is pretty nice. It does take a
lot of complexity from the clients and reduces the overhead while still
having a really nice interface.

So I am thinking we just need a core wpa_supplicant function that
creates a unique string for each BSS. And that has to take at least the
SSID into account, because of access point like the one above. For the
D-Bus API, it is just a string anyway, so nobody really cares. I don't
think we can easily fix it in the old API, but the new API with the BSS
struct it should be able to handle this.

Also I like to propose another change for some of the signals. For
example when notifying about an added BSS:

	BSSAdded(object path, dict properties)

If we send out the actual properties of the BSS along with its object
path, we make it a lot simpler for the clients to track them. It also
removes potential race conditions during the async messages send after a
scan to retrieve the initial properties.

Similar changes could be made for InterfaceCreated, NetworkAdd and
BlobAdded of course.

For initially bootstrapping from an already running wpa_supplicant, an
extra method like GetBSSs that returns a dict of a dict would be
helpful. The keys of the first dict are the object paths of each BSS and
the child dict contains the BSS properties. This would reduce the round
trips a lot.

Regards

Marcel