How to handle multiple SSIDs with the same BSS

[Dan Williams]

On Fri, 2009-12-25 at 15:25 -0800, Marcel Holtmann wrote:
> 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.

Agreed.

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

Agreed.

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

Yup.

Dan