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 <d...@laptop.org>: > 2009/8/7 Martin Langhoff <mar...@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? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
