> 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 <[email protected]>: >> 2009/8/7 Martin Langhoff <[email protected]>: >>> 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. Peter _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
