How to handle multiple SSIDs with the same BSS

[Marcel Holtmann]

Hi Jouni,

> > 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.
> 
> OK. Assuming the BSS interface remains, it would sound simplest to just
> concatenate hexdump of the SSID into the object path.

I would go for this one.

> > 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.
> 
> (bssid|ssid) will map as easily to internal data, so that should be
> fine.
> 
> > The main issue is that the supplicant doesn't really provide a cached
> > scan list at all, so the APs are somewhat transient.
> 
> This can be changed.. Especially if we start seeing more specific scans
> (e.g., scan only couple of channels or couple of SSIDs) clearing other
> entries. It would sound reasonable to make wpa_supplicant maintain a
> separate BSS table and just use the scan results to update it with
> timeouts for aging BSS entries. The D-Bus API would then use mainly the
> BSS table and would not really need to touch the raw scan results
> directly. This seems to work fine with the new D-Bus API as currently
> defined.

I like the idea of internal aging inside wpa_supplicant. That would make
it certainly easier for clients to stay up-to-date.

> > 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.
> 
> This sounds helpful since I would expect most clients to need the
> information anyway immediately after receiving the signal.

When changing to BSSAdded(object path, dict properties) we get this
right away, too. And for BSS already in the cache we just use the
PropertiesChanged(dict properties) signal.

> > 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.
> 
> We need to have a way of fetching all the current BSS information from
> wpa_supplicant somehow. Whether this is through the BSS interface or
> with a new method is a secondary question. Though, in some cases, it
> might be useful to be able to fetch this information one BSS at the time
> due to size limitations(?).

We want to add an interface method GetBSSs that returns all current
known BSS with their object path and properties (dict of dict). So we
can do it actually with just one method call.

Together with the modified BSSAdded signal we can get all information
with minimum round-trips.

Regards

Marcel