[Sugar-devel] meshing XOs with netbooks (WAS: Re: [Bugs] #79 NORM: SOAS should mesh network when possible)

[Gary C Martin]

On 10 Jun 2009, at 00:53, Martin Dengler wrote:

> On Wed, Jun 10, 2009 at 01:20:41AM +0200, Sean DALY wrote:
>> Hmmm this is an opportunity to display my ignorance and/or confusion,
>> but my XOs usually just "find" each other on the mesh
>
> Unfortunately this 'just "find"' is actually a complex process
> involving a few different software components whose interactions are a
> bit brittle (not prone to work when one/more software component is
> upgraded).  So it's really natural that the normal reasoning will lead
> to confusion.  I'm not the best or most available person to explain
> the details, though, sorry.

To my knowledge, XOs running OLPC builds go through a (far too long)  
cycle where they try each of the 3 mesh channels, twice through,  
looking for a school server providing mesh; then if no school server  
is found on the mesh it will auto-connect to your 'favourite' AP; if  
that fails you'll be un-ceremonially dumped on mesh channel 1, in the  
hope that other XO mesh users will land there later (slowly swamping  
the wifi spectrum down at ch1 unless users manually click on another  
mesh channel).

>> ... a club the netbooks can't belong to... so back on the XOs I have
>> to hunt and click on the wireless network for each one (making the
>> other XO avatars disappear, etc).
>
> Yup - the XOs on the "mesh" (802.11s draft) can't see
> {XOs,Sugars}-connected-to-jabber-servers, unless the meshed XOs are
> themselves connected to the same jabber server via inter-networking
> feats completely beyond my (and any OLPC deployments', AFAIC) ken.
>
>> There's no way to designate a favorite AP I guess?

Yep, by authenticating/logging in to an AP. The XO will (eventually)  
get around to looking for each AP you have authenticated with (after  
it's sniffed all 3 mesh channels for a school server, twice).

> Not really[1], and I'm only slightly oversimplifying/guessing about
> everything you mean (I take it you mean you want it to always connect
> to that AP even though the mesh devices are around).  The key for
> others/google is that you're talking about an OLPC build, not SoaS, so
> my "no" is completely invalid for other sugar builds (thankfully).
>
> When I was running OLPC builds as a G1G1 user I'd just always disable
> the mesh device:
>
> echo "echo 0 > /sys/class/net/eth0/lbs_mesh" >> /etc/rc.local
>
>> I had thought the jabber server was necessary for local
>> collaboration

Nope. Jabber server is actually a way to make arbitrary groups  
unrelated to network topology, as long as you all have access to the  
jabber server. It's a great way to have multiple custom collaboration  
rooms, absolutely no Sugar code changes at all. Just need to set-up  
several jabber servers for each group, could be on one physical server  
using virtual hosts on the same box – like most web provides do for  
http web servers...

> What do you mean by "local"?
>
>> ... which seemed counterintuitive (two machines on the
>> table needing external Internet + jabber server to see each other).
>
> To "see other Sugar learners in the Neighbourhood view", they do.
> Unless we're talking about XOs with an OLPC build and one uses the
> mesh.  But then they can't talk to non-XOs not using the mesh.

Just blank out the jabber server, and they'll broadcast on the local  
network.

There's another 'non-mesh' option possible for the '3 kids under a  
tree' case. They will likely have no AP/infrastructure to connect to,  
so blanking the jabber server is not an option. For them the existing  
local-link config would be very viable solution, but there's no Sugar  
UI for it yet. There was some talk for 0.86, and Tomeu and I did  
briefly use the idea between his and my laptop when we were without a  
common network and needed to transfer files...

Worked just fine – but then I set it up with my Mac, and we all know  
'they just work' ;-b

Regards,
--Gary

>> I hope the draft mesh in those million XOs is not too different from
>> the approved mesh :-)
>
> Optimistic.  This is all I can find, and to my layman's eyes it's not
> promising (as one would expect bewteen a 2-3-years-pre-standard
> implementation and the standard implementation of a wickedly complex
> standard):
> http://www.fruct.org/images/contentmedia/S4_n8xx_olpc_connectivity.pdf
>
>
>> thanks
>>
>> Sean
>
> Martin
>
> 1. http://www.mail-archive.com/devel@lists.laptop.org/msg12281.html
>