ESSIDs and BSSIDs, NM and Sugar

Martin Langhoff martin.langhoff at
Fri Aug 7 10:19: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>:
> 2009/8/7 Martin Langhoff <martin at>:
>> 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?


 martin.langhoff at
 martin at -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first

More information about the Devel mailing list