[Sugar-devel] ESSIDs and BSSIDs, NM and Sugar

[Dan Williams]

On Fri, 2009-08-07 at 16:23 +0200, Tomeu Vizoso wrote:
> On Fri, Aug 7, 2009 at 16:19, Martin Langhoff<martin.langhoff at gmail.com> wrote:
> > Following the "let's make Sugar more deployable" theme that Daniel
> > started a while ago, I am looking at something that Reuben mentioned
> > last week he discovered in the field. Apparently, the Sugar + NM
> > combination we ship (on XO OS 802) cannot do the BSSID migration that
> > you would expect.
> >
> > In other words, if you have a school with more than 1 AP, you should
> > normally set all the APs to the same ESSID, set them on different
> > channels, work on the tx power if there are more than 1 per channel,
> > etc. With such a setup, clients will dynamically assess which BSSID
> > has better signal / noise and associate to that one.
> >
> > But we seem to fail at this. With our current stack we will always
> > reassociate to the first BSSID we associated for that ESSID. See below
> > for a bit of sleuthing...
> >
> > 2009/8/6 Daniel Drake <dsd at laptop.org>:
> >> 2009/8/7 Martin Langhoff <martin at laptop.org>:
> >>> Apparently, NM saves the BSSID (or the channel?) in its state file in
> >>> .sugar (networks.conf?). So once you associate to network 'foo' one
> >>> one BSSID, it will only ever reconned to that BSSID.
> >>
> >> No, this is Sugar that manages this file. So if there is any bug here,
> >> it's a sugar bug.
> >
> > Just checked - ~/,sugar/default/nm/networks.cfg has a 'bssids' line
> > for each ESSID. I don't have a chance to test here now (lack of gear &
> > time here in Lima) but this will be interesting to track down.
> >
> >  ~~~
> >
> > Maybe there is something wrong in how we save multiple BSSIDs? Or
> > maybe we shouldn't save the BSSID, and stick to just ESSIDs?
> 
> Dan, do you know anything about this?

NM is not normally involved in BSSID <-> BSSID roaming; that is purely
the responsibility of the supplicant and driver.  I'm pretty sure you
guys are locking the BSSID in the NMConnection details you're sending,
which means NM is only sending the ESSID to the supplicant.

The supplicant then performs a scan, and if there is a compatible AP
with the given ESSID, will associate to it.  If the driver looses
association to that AP, the supplicant will either perform an additional
scan, or use the cached scan list to find a better AP with the same
ESSID.  If it finds another AP with the configured ESSID, it will
attempt to associate to that AP.

The driver/firmware are also allowed to roam between BSSIDs of the same
ESSID, but I don't think the current libertas firmware actually does
that.

Thus, it's all up to the supplicant.  Set up debugging options on
wpa_supplicant (-dddt) in the dbus-activation file
in /usr/share/dbus-1/system-services/ and try to reproduce the problem.
That should show pretty clearly what's going on.

Dan