How to handle multiple SSIDs with the same BSS

[Jouni Malinen]

On Fri, Dec 25, 2009 at 01:27:01PM -0600, Dan Williams wrote:

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

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

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

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


PS.

I imported the new D-Bus API documentation from Witold into the
wpa_supplicant doxygen documentation (doc/dbus.doxygen) and added an
example python script (wpa_supplicant/examples/wpas-dbus-new.py) for
using the new API. I would appreciate patches to improve these and to
keep them up-to-date with API changes that we may do on the actual
implementation in wpa_supplicant.

-- 
Jouni Malinen                                            PGP id EFC895FA