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

Peter Robinson pbrobinson at gmail.com
Fri Aug 7 10:24:06 EDT 2009

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

Is there any reason we can't use the same code that NM uses for this
in gnome or wherever it is that its implemented elsewhere? It seems
silly to reinvent the wheel. This would also have the nice side effect
on the XO 1.5 with the dual gnome/sugar desktop environment of only
needing to put the AP password in once for both environments.


More information about the Devel mailing list