[Server-devel] "XO-1 classrooms" don't reliably connect to many/most Wifi AP's

James Cameron quozl at laptop.org
Tue Feb 11 01:38:49 EST 2014

On Tue, Feb 11, 2014 at 07:24:33AM +0100, Jon Nettleton wrote:
> On Tue, Feb 11, 2014 at 7:08 AM, James Cameron <quozl at laptop.org> wrote:
> > On Mon, Feb 10, 2014 at 11:31:39AM +1100, James Cameron wrote:
> >> On Sun, Feb 09, 2014 at 07:18:49PM -0500, Kevin Gordon Gmail wrote:
> >> > Tp link set as 3g router mode, with usb Sierra wireless usb modem,
> >> > set to channel 11, 80211g only, wpa2 pal security. Running stock
> >> > f/w.
> >>
> >> Terry found that channel 1 was the most afflicted.  I suspect, but I
> >> haven't checked, that the idle mesh only uses channel 1, but it also
> >> use whatever channel the laptop is associated with.
> >
> > Tim's results from Open Firmware show that the idle mesh switches to
> > whatever channel is being used for association with an access point.
> This has to be the case because there is only one radio, so both
> 802.11s and 802.11b/g have to be configured for the same channel.

And being off-channel would be too costly.

> > So while we would normally see an operating mesh on 1, 6 and 11, it
> > can be seen on other channels as well.
> >
> > The underlying fault was somewhat channel specific ... because the
> > scans are done in sets; (1,2,3,4), (5,6,7,8), (9,10,11,12).  If a mesh
> > was heard on channel 1 then the scan results for channels 2, 3 and 4
> > will have been lost.  If a mesh was heard on channel 9, then the scan
> > results for channels 10, 11 and 12 will have been lost.
> >
> I think really what we need to do is have a better workflow for
> detecting connectivity, not much different from how we are handling
> ad-hoc on the later model XO's
> I think on initial boot, or waking from suspend and the previous wifi
> state was not connected, we need to disable the mesh interface and
> scan for infrastructure AP's.  Then if this fails we can either scan
> for ad-hoc or bring up the mesh interface and look for a mesh network
> to connect to.  I think besides driver bugs we have a general problem
> of trying to do too much at the same time with a single radio.
> any takers on this workflow for network discovery?

Sounds interesting, but can't commit myself.  But it may be something
that Sugar Labs might be interested in.

It does look like it would be possible to scan for APs, ad-hoc, and
mesh at the same time, without having to bring up the mesh interface
first.  All within about 440ms.

Those mesh probe responses are useful after all.  ;-)

James Cameron

More information about the Server-devel mailing list