Re: [Testing] os240py - collaboration over wireless

On 31 May 2010 00:03, James Cameron <quozl <at> laptop.org> wrote:
> I've reproduced "no sharing" over mesh on os240py.
>
> Activity sharing works via access point.
>
> Activity sharing works via "Create new wireless network" aka ad-hoc.

I'm pretty sure this will be another case of there being no default
multicast route.

Daniel

Re: [Testing] os240py - collaboration over wireless

On Mon, May 31, 2010 at 06:54:28PM -0500, Daniel Drake wrote:
> I'm pretty sure this will be another case of there being no default
> multicast route.

Yep, that's it.  Sugar is entirely relying on the existence of this
multicast route, and it is not present on os240py.

It can temporarily be added after mesh is started:

	ip route add 224.0.0.0/4 dev msh0

And after that, I've tested that Chat activity when shared appears in
Neighbourhood View of other laptops, and that another laptop running
os240py can join it.  Conversation works fine.

Bernie, modules/base/kspost.10.core.inc in olpc-os-builder handles this
for ad-hoc.  Presumably it needs a similar thing for mesh.

--

-- 
James Cameron
http://quozl.linux.org.au/

Re: [Testing] os240py - collaboration over wireless

>> Activity sharing works via access point.
>> 
>> Activity sharing works via "Create new wireless network" aka ad-hoc.
> 
> I'm pretty sure this will be another case of there being no default
> multicast route.

I normally use wired ethernet, not wireless.  Back some months, I asked
how come all the XOs on my ethernet saw each other (i.e., there were
icons for all the XOs in every system's Neighborhood View), when some
systems had static ethernet IP-addresses (192.168...) and other systems
had "ad-hoc network" IP-addresses (at that time, the ad-hoc network was
assigning IP-addresses in the 10...  range).  The answer I got was that
the "presence detection" (or something) capability used multicast,
rather than depending upon "standard" interface defined IP-addresses.

What I noticed with os240py was that as soon as both system had
connected to the same wireless Mesh channel, each saw the other (i.e.,
Neighborhood View at both systems showed the icons for both systems).
Are you saying that the multicast capability that was explained to me
months ago was NOT active in os240py with only Mesh connected ?

[ Is there a command that I can manually enter at a Mesh-connected
os240py system to activate such a 'default multicast route' ? ]

mikus

Re: [Testing] os240py - collaboration over wireless

os240py is based on Sugar 0.88, but months ago we were talking to you
about Sugar 0.84, so chances are there is a change to how presence is
transported.

os240py unmodified, without a multicast route, associated with mesh does
show XO icons in the neighbourhood view.  Yet it does not show shared
activities.  Therefore it can't be using the same underlying technique.

We may have to unlearn things we had learned.

--

-- 
James Cameron
http://quozl.linux.org.au/

Re: [Testing] os240py - collaboration over wireless

On Mon, May 31, 2010 at 08:59:49PM -0500, Mikus Grinbergs wrote:
> The answer I got was that the "presence detection" (or something)
> capability used multicast, rather than depending upon "standard"
> interface defined IP-addresses.

I've just booted one laptop on os240py to use mesh, but with packet
capturing on one that was already booted.  The captured packets were
interesting.  After the booting laptop established an IP address, there
was a multicast DNS exchange, followed by an explicit connection to the
presence service on TCP port 5298 on the already booted laptop.

> What I noticed with os240py was that as soon as both system had
> connected to the same wireless Mesh channel, each saw the other (i.e.,
> Neighborhood View at both systems showed the icons for both systems).

I see that too.

> Are you saying that the multicast capability that was explained to me
> months ago was NOT active in os240py with only Mesh connected ?

Yes, you can verify this by using "ip route list", and on os240py there
is no multicast route, but in the same network configuration on os802
there is.

> [ Is there a command that I can manually enter at a Mesh-connected
> os240py system to activate such a 'default multicast route' ? ]

The "ip route add" command I gave will do this.  The "ip route list"
command will show the change.

[SoaS] [Testing] soas20100531-rawhide Mirabelle USB-testing

http://archive.fedoraproject.org/pub/alt/nightly-composes/soas/soas-i386-20100531.03.iso

(Pulled from rawhide)
http://infrastructure.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/Packages/....

0.88.0
Soas 3 Mirabelle
script created 4 GB USB ACER Aspire One Wireless (Apple Airport Extreme 
2 Bridged)

Activities;  * (see footnotes) All others start and stop and write to 
journal.  > =Updated in CP
Browse 115, Etoys 115, Chat 66*(1), Write 69, IRC 6, Record 66>67*(2), 
Turtle Blocks 88, Log 23, Terminal 31, Physics 4.

Control Panel:
Keyboard selection popup does not work

Presence Service works

Register appears to have failed? No pop up then resumed jabber connection.

(1) Starts and appears on F1 Neighborhood where it is join-able from 
Originating PC; Not tested farther
Chat Log:
>   File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 
> 630, in call_blocking
>     message, timeout)
> DBusException: org.freedesktop.Telepathy.Error.InvalidHandle: handle 0 
> is not currently a valid contact handle (type 1)

multicast route missing on ad-hoc+mesh (was: Re: [Testing] os240py - collaboration over wireless)

Excerpts from James Cameron's message of Tue Jun 01 00:42:38 +0000 2010:
> Yep, that's it.  Sugar is entirely relying on the existence of this
> multicast route, and it is not present on os240py.
> 
> It can temporarily be added after mesh is started:
> 
>     ip route add 224.0.0.0/4 dev msh0
[...]
> Bernie, modules/base/kspost.10.core.inc in olpc-os-builder handles this
> for ad-hoc.  Presumably it needs a similar thing for mesh.

What's the upstream ticket for this bug (the multicast route being missing)?
This might explain quite a bit of the trouble I had with collaboration
(though not all of it).

Sascha
--

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel

Browse activity not working

_______________________________________________
Devel mailing list
Devel <at> lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: multicast route missing on ad-hoc+mesh (was: Re: [Testing] os240py - collaboration over wireless)

On 1 June 2010 02:55, Sascha Silbe
<sascha-ml-ui-sugar-olpc-devel <at> silbe.org> wrote:
> Excerpts from James Cameron's message of Tue Jun 01 00:42:38 +0000 2010:
>> Yep, that's it.  Sugar is entirely relying on the existence of this
>> multicast route, and it is not present on os240py.
>>
>> It can temporarily be added after mesh is started:
>>
>>     ip route add 224.0.0.0/4 dev msh0
> [...]
>> Bernie, modules/base/kspost.10.core.inc in olpc-os-builder handles this
>> for ad-hoc.  Presumably it needs a similar thing for mesh.
>
> What's the upstream ticket for this bug (the multicast route being missing)?
> This might explain quite a bit of the trouble I had with collaboration
> (though not all of it).

You can find the discussion on the NetworkManager list. It wasn't
concluded, Dan Williams needs to be prodded more so that we can come
up with a solution.

Daniel

Re: multicast route missing on ad-hoc+mesh

On 06/01/2010 03:32 PM, Daniel Drake wrote:
> On 1 June 2010 02:55, Sascha Silbe
> <sascha-ml-ui-sugar-olpc-devel <at> silbe.org>  wrote:
>> Excerpts from James Cameron's message of Tue Jun 01 00:42:38 +0000 2010:
>>> Yep, that's it.  Sugar is entirely relying on the existence of this
>>> multicast route, and it is not present on os240py.
>>>
>>> It can temporarily be added after mesh is started:
>>>
>>>      ip route add 224.0.0.0/4 dev msh0
>> [...]
>>> Bernie, modules/base/kspost.10.core.inc in olpc-os-builder handles this
>>> for ad-hoc.  Presumably it needs a similar thing for mesh.
>>
>> What's the upstream ticket for this bug (the multicast route being missing)?
>> This might explain quite a bit of the trouble I had with collaboration
>> (though not all of it).
>
> You can find the discussion on the NetworkManager list. It wasn't
> concluded, Dan Williams needs to be prodded more so that we can come
> up with a solution.
>
> Daniel

Ok, testing with setting the route helped here, too. For some reason, it 
took a while until I could share.

Daniel, I searched a bit on the NM-list but could not find that previous 
discussion, can you point me to it?

Thanks,
    Simon

PS: as mesh support will land in 0.84 soon, we want to set our system up 
for that http://bugs.sugarlabs.org/ticket/2015.