Re: [Sugar-devel] ESSIDs and BSSIDs, NM and Sugar
> 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 : >> 2009/8/7 Martin Langhoff : >>> 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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] ESSIDs and BSSIDs, NM and Sugar
On Fri, Aug 7, 2009 at 16:19, Martin Langhoff 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 : >> 2009/8/7 Martin Langhoff : >>> 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? Thanks, Tomeu > 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-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] ESSIDs and BSSIDs, NM and Sugar
On Fri, 2009-08-07 at 16:23 +0200, Tomeu Vizoso wrote: > On Fri, Aug 7, 2009 at 16:19, Martin Langhoff > 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 : > >> 2009/8/7 Martin Langhoff : > >>> 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] ESSIDs and BSSIDs, NM and Sugar
Attached please find a program that can be run from the Terminal
activity or the text console to display signal level, noise level and
link quality at ten updates per second.
It is useful for performing simple measurements of RF coverage on an XO
associated with an access point.
The levels are expressed as circles of varying radii. Press q to quit.
Tested on OLPC build 802 and debxo.
--
James Cameron
http://quozl.linux.org.au/
#!/usr/bin/python
"""
Signal Strength Meter
Copyright (C) 2009 James Cameron (qu...@laptop.org)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
import sys, pygame
license = [
"Signal Strength Meter",
"Copyright (C) 2009 James Cameron ",
" ",
"This program comes with ABSOLUTELY NO WARRANTY;",
"for details see source.",
" ",
"This is free software, and you are welcome to ",
"redistribute it under certain conditions; see ",
"source for details.",
" "
]
pause = 100 # milliseconds between screen updates
license_show_time = 10 # number of seconds to show license for
thickness = 4 # thickness of circles in pixels
fonts = ('DejaVuSansMono.ttf', 'DejaVuLGCSansMono.ttf')
fontpaths = ('/usr/share/fonts/dejavu/', '/usr/share/fonts/truetype/ttf-dejavu/')
# colours
c_license = (0, 0, 0)
c_link = (0, 0, 192)
c_signal = (0, 192, 0)
c_noise = (192, 0, 0)
def get_rf():
""" obtain wireless status from first network interface """
fp = open('/proc/net/wireless', 'r')
head = fp.readline()
head = fp.readline()
line = fp.readline()
fp.close()
(x, x, link, signal, noise, x, x, x, x, x, x) = line.split()
return (int(link.replace('.', ' ')),
int(signal.replace('.', ' ')),
int(noise.replace('.', ' ')))
# what to do when user wants to leave
def op_quit():
sys.exit()
# control keyboard table, relates keys to functions
kb_table_control = {
pygame.K_d: op_quit,
}
# normal keyboard table, relates keys to functions
kb_table_normal = {
pygame.K_q: op_quit,
}
def kb(event):
""" handle keyboard events from user """
# ignore the shift and control keys
if event.key == pygame.K_LSHIFT or event.key == pygame.K_RSHIFT: return
if event.key == pygame.K_LCTRL or event.key == pygame.K_RCTRL: return
# check for control key sequences pressed
if (event.mod == pygame.KMOD_CTRL or
event.mod == pygame.KMOD_LCTRL or
event.mod == pygame.KMOD_RCTRL):
if kb_table_control.has_key(event.key):
handler = kb_table_control[event.key]
handler()
return
# check for normal keys pressed
if kb_table_normal.has_key(event.key):
handler = kb_table_normal[event.key]
handler()
return
class FontCache:
def __init__(self):
self.cache = {}
def read(self, names, size):
if names == None:
return pygame.font.Font(None, size)
for name in names:
for path in fontpaths:
try:
return pygame.font.Font(path + name, size)
except:
continue
return pygame.font.Font(None, size)
def get(self, names, size):
key = (names, size)
if key not in self.cache:
self.cache[key] = self.read(names, size)
return self.cache[key]
def draw_license():
fn = fc.get(fonts, 35)
x = 50
y = 394
for line in license:
ts = fn.render(line, 1, c_license, bg)
tr = ts.get_rect(left=x, top=y)
y = tr.bottom
dirty.append(screen.blit(ts, tr))
def draw_labels():
fn = fc.get(fonts, 35)
ts = fn.render('LINK QUALITY', 1, c_link, bg)
tr = ts.get_rect(centerx=width/2, top=0)
dirty.append(screen.blit(ts, tr))
ts = fn.render('SIGNAL LEVEL', 1, c_signal, bg)
tr = ts.get_rect(left=0, bottom=height)
dirty.append(screen.blit(ts, tr))
ts = fn.render('NOISE LEVEL', 1, c_noise, bg)
tr = ts.get_rect(right=width, bottom=height)
dirty.append(screen.blit(ts, tr))
def draw_item(show, colour, x, y, radius, v):
if not show:
colour = bg
if radius < 0:
radius = 0
p = pygame.draw.circle(screen, colour, (x, y), radius+thickness, thickness)
fn = fc.get(fonts, 50)
ts = fn.render(v, 1, colour, bg)
tr = ts.get_rect(centerx=x, centery=y)
Re: [Sugar-devel] ESSIDs and BSSIDs, NM and Sugar
On Tue, Aug 11, 2009 at 11:49:21AM -0300, Andr?s Nacelle wrote: > First of all thanks James for taking your time and reading the stuff I > send and giving me such a complete response. Getting into what you > were saying, I'm aware of the high dynamics under the signal sensing > and reception, because of that I managed to run the test in a big > storehouse 65 meters long and 35 meters wide, completely empty (except > because of me and the equipment). In addition is in a place where > there's almost no interference from other wireless devises. This way I > tried to minimise the influence of variables out of my management. Good, thanks. > The concept of the XO taking the decision to connect to the "best" AP > is what we are chasing. But the definition of best is not that easy > and the behavior of the XO is not that as desired. What I'm saying > here is that best AP also means no overloading a single AP when there > is another one nearby with a reasonable quality. I wonder if the wireless firmware on the XO can determine the load on an AP. > In the other hand the XO doesn't stay in the same AP, it changes all > the time even when there's 14 dBm power difference between each signal > instead of staying connected to the same AP. There should be a way to > make those connections more stable. I'd be more interested in the samples of signal level captured by iwconfig as an XO moves from one AP to another. > I've been using two different ways for doing this. The first is > running 15 times the iwlist eth0 sc, and doing the average. This I did > it in different regions of the testing area. [...] Okay. I've compared the scan results against the associated results, and they tend to be different and slower. They are different in that the scan results are optimistic, by up to 10 dBm. They are slower because the scan takes much longer. It would be interesting to test whether the XOs migrate from one AP to another if they were not regularly scanning. To test that, on a unit, manually stop Network Manager, associate with the AP, obtain IP, and then monitor. # /etc/init.d/NetworkManager stop # iwconfig eth0 essid quozl.linux.org.au # dhclient eth0 (the last two steps take four seconds for me, but six to eight seconds for Network Manager). As an aside, the program ssm.py that I wrote yesterday can be used to demonstrate an odd behaviour ... close the antennae, then place a hand over one antenna then the other. The variations in signal level and link quality suggest that the wireless chipset is preferring the left-hand antenna, which is coincidently the one with the shortest internal RF cable. It also less frequently tries the other antenna. (I wish more data was exposed). -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
