Re: [Sugar-devel] Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Gonzalo Odiard]

Fantastic news!

Gonzalo

On Thu, Sep 18, 2014 at 1:29 AM, James Cameron  wrote:

> On Thu, Sep 18, 2014 at 10:38:56AM +1000, James Cameron wrote:
> > Adding a gateway fixes Salut over ad-hoc.
> >
> > For instance, using the pre-defined Ad-hoc Network 11, then typing
> > this command, makes buddy icons and shared activities appear:
> >
> >   sudo ip route add default via 169.254.1.1
> >
> > The IP chosen need not exist on the network.
> >
> > Therefore, it wasn't the manual address configuration that you did
> > which fixed it, it was the addition of a gateway.
> >
> > Perhaps Salut was changed from Fedora 18 to Fedora 20 to require a
> > default route.
>
> That would be a worthwhile investigation in case anybody is
> interested, but for the moment I've pushed a patch that creates this
> default route.
>
>
> http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=bdd624b5038a0264669cc032061ce779521fbe59
>
> >
> > Also, there's some other problem that causes split ad-hoc networks; on
> > my desk at the moment are four XO-4 that have partitioned themselves
> > into two ad-hoc networks both named "Ad-hoc Network 11".  The two
> > groups can ping each other, show buddy icons, share activities, but
> > cannot ping outside their group.
> >
> > I've updated
> > http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
> > to add your /etc/environment suggestion.
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Gonzalo Odiard

SugarLabs - Software for children learning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[James Cameron]

On Thu, Sep 18, 2014 at 10:38:56AM +1000, James Cameron wrote:
> Adding a gateway fixes Salut over ad-hoc.
> 
> For instance, using the pre-defined Ad-hoc Network 11, then typing
> this command, makes buddy icons and shared activities appear:
> 
>   sudo ip route add default via 169.254.1.1
> 
> The IP chosen need not exist on the network.
> 
> Therefore, it wasn't the manual address configuration that you did
> which fixed it, it was the addition of a gateway.
> 
> Perhaps Salut was changed from Fedora 18 to Fedora 20 to require a
> default route.

That would be a worthwhile investigation in case anybody is
interested, but for the moment I've pushed a patch that creates this
default route.

http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=bdd624b5038a0264669cc032061ce779521fbe59

> 
> Also, there's some other problem that causes split ad-hoc networks; on
> my desk at the moment are four XO-4 that have partitioned themselves
> into two ad-hoc networks both named "Ad-hoc Network 11".  The two
> groups can ping each other, show buddy icons, share activities, but
> cannot ping outside their group.
> 
> I've updated
> http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
> to add your /etc/environment suggestion.
> 
> -- 
> James Cameron
> http://quozl.linux.org.au/

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[James Cameron]

Adding a gateway fixes Salut over ad-hoc.

For instance, using the pre-defined Ad-hoc Network 11, then typing
this command, makes buddy icons and shared activities appear:

sudo ip route add default via 169.254.1.1

The IP chosen need not exist on the network.

Therefore, it wasn't the manual address configuration that you did
which fixed it, it was the addition of a gateway.

Perhaps Salut was changed from Fedora 18 to Fedora 20 to require a
default route.

Also, there's some other problem that causes split ad-hoc networks; on
my desk at the moment are four XO-4 that have partitioned themselves
into two ad-hoc networks both named "Ad-hoc Network 11".  The two
groups can ping each other, show buddy icons, share activities, but
cannot ping outside their group.

I've updated
http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
to add your /etc/environment suggestion.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Martin Abente]

Here is the full log of that test: http://www.fpaste.org/134374/41098567/

On Wed, Sep 17, 2014 at 4:26 PM, Martin Abente <
martin.abente.lah...@gmail.com> wrote:

> I enabled telepathy-salut logs by adding these to /etc/environment (note
> that changing debug file does not work anymore):
>
> G_MESSAGES_DEBUG="all"
> SALUT_DEBUG="all"
> SALUT_LOGFILE=/home/olpc/salut.log
>
> I see a lot of activity when I connect to an access point (or to modified
> ad-hoc network), but I when connect to a normal Sugar ad-hoc network, I see
> this in the log:
>
>  ...
>
> (telepathy-salut:728): salut-DEBUG: gabble_capabilities_finalize: 0xab108
> (telepathy-salut:728): salut-DEBUG: salut_connection_finalize: Finalizing
> connection
> (telepathy-salut:728): tp-glib-DEBUG: no connections, and timed out
> tp-glib-Message: Exiting
>
> There is when the salut exits. I tried forcing it to not exit by adding
> this to /etc/environment:
>
> SALUT_PERSIST=1
>
>
> In that case, when I connect to the normal Sugar ad-hoc network, I see the
> "time out" message and the process keeps running, but no activity is logged
> until I re-connect to an access point or modified ad-hoc.
>
> So basically, even if the process keeps running the issue persist...
>
>
> On Wed, Sep 17, 2014 at 10:22 AM, Martin Abente <
> martin.abente.lah...@gmail.com> wrote:
>
>> Hello James,
>>
>> On Wed, Sep 17, 2014 at 5:18 AM, James Cameron  wrote:
>>
>>> On Tue, Sep 16, 2014 at 02:14:56PM -0400, Martin Abente wrote:
>>> > James, Gonzalo,
>>> >
>>> > Regarding the IBSS/Ad-hoc scenario, if I set the address manually,
>>> > collaborations work just fine. So this must be related to network
>>> > discovery.
>>>
>>> Thanks, that's interesting.  Can you tell me _how_ you set the address
>>> manually?  When I tried it there was no real difference:
>>
>>
>> My bad, here is what  I am doing:
>>
>> 1. Used a XO with fc18 build to create the "Sugar Ad-hoc Network 2".
>> 2. Then, from another XO with fc20 build, and before I connect to the
>> Ad-hoc 2 network, I edit that connection using nm-connection-editor:
>> (a)edit "IPv4 Settings" for the "Sugar Ad-hoc Network 2", (b) set the
>> method to "manual", (c) set the (address,mask,gateway). and save.
>> 3. Then, from the neighborhood, I connect to the ad-hoc 2 network and
>> everything works.
>>
>>
>>>
>>>
>>> http://wiki.laptop.org/go/User:Quozl/Fedora_20/Manual_network_configuration
>>>
>>> > My test goes like this:
>>> >
>>> > * I use one XO with fc18+S0.100 to create an ad-hoc network network.
>>> > * From another XO, with fc20+S0.102, I connect to that ad-hoc network.
>>> >
>>> > The second XO ip address does not match the first one's network.
>>>
>>> Can you tell me how it does not match?  It always matches when I try
>>> it; a link-local address 169.254.x.x valid to RFC 3927 is always
>>> assigned, as shown by "ip addr" command.
>>>
>>
>> You are right, thanks for the clarifications. I might have been confused
>> by previous tests.
>>
>> I have no idea why changing the method from "local-link" to "manual", and
>> manually assigning the address, mask and gateway makes such difference.
>>
>> If you want to try this, set the address and mask to its original/same
>> values, and for the gateway use the first XO address...
>>
>>
>>>
>>> http://en.wikipedia.org/wiki/Link-local_address
>>>
>>> > But when I manually configure it, then buddy icons appears and
>>> > collaboration works...
>>>
>>> When I enable Sugar debugging and use sugar-launch as before, a new
>>> interesting message is seen, "No active connection available" which is
>>> because neither Gabble nor Salut is running.
>>>
>>> % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
>>>
>>> ...
>>> 1410934106.660510 DEBUG root: Requesting public share of activity
>>> 3b34e9d6ce9f294d12cd79314f7946a2f8845be5.
>>> 1410934106.662832 DEBUG root: Share of activity
>>> 3b34e9d6ce9f294d12cd79314f7946a2f8845be5 failed: No active connection
>>> available.
>>> ...
>>>
>>> The error is reported by the __share_cb method of the Activity class.
>>>
>>> /usr/lib/python2.7/site-packages/sugar3/activity/activity.py:
>>>
>>> def __share_cb(self, ps, success, activity, err):
>>> if not success:
>>> logging.debug('Share of activity %s failed: %s.' %
>>>   (self._activity_id, err))
>>> return
>>>
>>> ...
>>>
>>> def share(self, private=False):
>>> ...
>>> pservice = presenceservice.get_instance()
>>> pservice.connect('activity-shared', self.__share_cb)
>>> pservice.share_activity(self, private=private)
>>>
>>> The error comes from the share_activity method of the PresenceService
>>> class.
>>>
>>> /usr/lib/python2.7/site-packages/sugar/presence/presenceservice.py
>>>
>>> def share_activity(self, activity, properties=None, private=True):
>>> ...
>>> connection_manager = get_connection_manager()
>>> account_path, connection = \
>>> connection_mana

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Martin Abente]

I enabled telepathy-salut logs by adding these to /etc/environment (note
that changing debug file does not work anymore):

G_MESSAGES_DEBUG="all"
SALUT_DEBUG="all"
SALUT_LOGFILE=/home/olpc/salut.log

I see a lot of activity when I connect to an access point (or to modified
ad-hoc network), but I when connect to a normal Sugar ad-hoc network, I see
this in the log:

 ...

(telepathy-salut:728): salut-DEBUG: gabble_capabilities_finalize: 0xab108
(telepathy-salut:728): salut-DEBUG: salut_connection_finalize: Finalizing
connection
(telepathy-salut:728): tp-glib-DEBUG: no connections, and timed out
tp-glib-Message: Exiting

There is when the salut exits. I tried forcing it to not exit by adding
this to /etc/environment:

SALUT_PERSIST=1


In that case, when I connect to the normal Sugar ad-hoc network, I see the
"time out" message and the process keeps running, but no activity is logged
until I re-connect to an access point or modified ad-hoc.

So basically, even if the process keeps running the issue persist...


On Wed, Sep 17, 2014 at 10:22 AM, Martin Abente <
martin.abente.lah...@gmail.com> wrote:

> Hello James,
>
> On Wed, Sep 17, 2014 at 5:18 AM, James Cameron  wrote:
>
>> On Tue, Sep 16, 2014 at 02:14:56PM -0400, Martin Abente wrote:
>> > James, Gonzalo,
>> >
>> > Regarding the IBSS/Ad-hoc scenario, if I set the address manually,
>> > collaborations work just fine. So this must be related to network
>> > discovery.
>>
>> Thanks, that's interesting.  Can you tell me _how_ you set the address
>> manually?  When I tried it there was no real difference:
>
>
> My bad, here is what  I am doing:
>
> 1. Used a XO with fc18 build to create the "Sugar Ad-hoc Network 2".
> 2. Then, from another XO with fc20 build, and before I connect to the
> Ad-hoc 2 network, I edit that connection using nm-connection-editor:
> (a)edit "IPv4 Settings" for the "Sugar Ad-hoc Network 2", (b) set the
> method to "manual", (c) set the (address,mask,gateway). and save.
> 3. Then, from the neighborhood, I connect to the ad-hoc 2 network and
> everything works.
>
>
>>
>>
>> http://wiki.laptop.org/go/User:Quozl/Fedora_20/Manual_network_configuration
>>
>> > My test goes like this:
>> >
>> > * I use one XO with fc18+S0.100 to create an ad-hoc network network.
>> > * From another XO, with fc20+S0.102, I connect to that ad-hoc network.
>> >
>> > The second XO ip address does not match the first one's network.
>>
>> Can you tell me how it does not match?  It always matches when I try
>> it; a link-local address 169.254.x.x valid to RFC 3927 is always
>> assigned, as shown by "ip addr" command.
>>
>
> You are right, thanks for the clarifications. I might have been confused
> by previous tests.
>
> I have no idea why changing the method from "local-link" to "manual", and
> manually assigning the address, mask and gateway makes such difference.
>
> If you want to try this, set the address and mask to its original/same
> values, and for the gateway use the first XO address...
>
>
>>
>> http://en.wikipedia.org/wiki/Link-local_address
>>
>> > But when I manually configure it, then buddy icons appears and
>> > collaboration works...
>>
>> When I enable Sugar debugging and use sugar-launch as before, a new
>> interesting message is seen, "No active connection available" which is
>> because neither Gabble nor Salut is running.
>>
>> % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
>>
>> ...
>> 1410934106.660510 DEBUG root: Requesting public share of activity
>> 3b34e9d6ce9f294d12cd79314f7946a2f8845be5.
>> 1410934106.662832 DEBUG root: Share of activity
>> 3b34e9d6ce9f294d12cd79314f7946a2f8845be5 failed: No active connection
>> available.
>> ...
>>
>> The error is reported by the __share_cb method of the Activity class.
>>
>> /usr/lib/python2.7/site-packages/sugar3/activity/activity.py:
>>
>> def __share_cb(self, ps, success, activity, err):
>> if not success:
>> logging.debug('Share of activity %s failed: %s.' %
>>   (self._activity_id, err))
>> return
>>
>> ...
>>
>> def share(self, private=False):
>> ...
>> pservice = presenceservice.get_instance()
>> pservice.connect('activity-shared', self.__share_cb)
>> pservice.share_activity(self, private=private)
>>
>> The error comes from the share_activity method of the PresenceService
>> class.
>>
>> /usr/lib/python2.7/site-packages/sugar/presence/presenceservice.py
>>
>> def share_activity(self, activity, properties=None, private=True):
>> ...
>> connection_manager = get_connection_manager()
>> account_path, connection = \
>> connection_manager.get_preferred_connection()
>>
>> if connection is None:
>> self.emit('activity-shared', False, None,
>>   'No active connection available')
>> return
>>
>> /usr/lib/python2.7/site-packages/sugar/presence/connectionmanager.py
>>
>> def get_preferred_connection(se

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Martin Abente]

Hello James,

On Wed, Sep 17, 2014 at 5:18 AM, James Cameron  wrote:

> On Tue, Sep 16, 2014 at 02:14:56PM -0400, Martin Abente wrote:
> > James, Gonzalo,
> >
> > Regarding the IBSS/Ad-hoc scenario, if I set the address manually,
> > collaborations work just fine. So this must be related to network
> > discovery.
>
> Thanks, that's interesting.  Can you tell me _how_ you set the address
> manually?  When I tried it there was no real difference:


My bad, here is what  I am doing:

1. Used a XO with fc18 build to create the "Sugar Ad-hoc Network 2".
2. Then, from another XO with fc20 build, and before I connect to the
Ad-hoc 2 network, I edit that connection using nm-connection-editor:
(a)edit "IPv4 Settings" for the "Sugar Ad-hoc Network 2", (b) set the
method to "manual", (c) set the (address,mask,gateway). and save.
3. Then, from the neighborhood, I connect to the ad-hoc 2 network and
everything works.


>
> http://wiki.laptop.org/go/User:Quozl/Fedora_20/Manual_network_configuration
>
> > My test goes like this:
> >
> > * I use one XO with fc18+S0.100 to create an ad-hoc network network.
> > * From another XO, with fc20+S0.102, I connect to that ad-hoc network.
> >
> > The second XO ip address does not match the first one's network.
>
> Can you tell me how it does not match?  It always matches when I try
> it; a link-local address 169.254.x.x valid to RFC 3927 is always
> assigned, as shown by "ip addr" command.
>

You are right, thanks for the clarifications. I might have been confused by
previous tests.

I have no idea why changing the method from "local-link" to "manual", and
manually assigning the address, mask and gateway makes such difference.

If you want to try this, set the address and mask to its original/same
values, and for the gateway use the first XO address...


>
> http://en.wikipedia.org/wiki/Link-local_address
>
> > But when I manually configure it, then buddy icons appears and
> > collaboration works...
>
> When I enable Sugar debugging and use sugar-launch as before, a new
> interesting message is seen, "No active connection available" which is
> because neither Gabble nor Salut is running.
>
> % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
>
> ...
> 1410934106.660510 DEBUG root: Requesting public share of activity
> 3b34e9d6ce9f294d12cd79314f7946a2f8845be5.
> 1410934106.662832 DEBUG root: Share of activity
> 3b34e9d6ce9f294d12cd79314f7946a2f8845be5 failed: No active connection
> available.
> ...
>
> The error is reported by the __share_cb method of the Activity class.
>
> /usr/lib/python2.7/site-packages/sugar3/activity/activity.py:
>
> def __share_cb(self, ps, success, activity, err):
> if not success:
> logging.debug('Share of activity %s failed: %s.' %
>   (self._activity_id, err))
> return
>
> ...
>
> def share(self, private=False):
> ...
> pservice = presenceservice.get_instance()
> pservice.connect('activity-shared', self.__share_cb)
> pservice.share_activity(self, private=private)
>
> The error comes from the share_activity method of the PresenceService
> class.
>
> /usr/lib/python2.7/site-packages/sugar/presence/presenceservice.py
>
> def share_activity(self, activity, properties=None, private=True):
> ...
> connection_manager = get_connection_manager()
> account_path, connection = \
> connection_manager.get_preferred_connection()
>
> if connection is None:
> self.emit('activity-shared', False, None,
>   'No active connection available')
> return
>
> /usr/lib/python2.7/site-packages/sugar/presence/connectionmanager.py
>
> def get_preferred_connection(self):
> best_connection = None, None
> for account_path, connection in
> self._connections_per_account.items():
> if 'salut' in account_path and connection.connected:
> best_connection = account_path, connection.connection
> elif 'gabble' in account_path and connection.connected:
> best_connection = account_path, connection.connection
> break
> return best_connection
>

I followed the same path yesterday, and could not figure it out.

Similarly in /usr/lib/python2.7/site-packages/jarabe/model/neighborhood.py:

def _start_listening(self):
bus = dbus.Bus()
obj = bus.get_object(ACCOUNT_MANAGER_SERVICE, self.object_path)
obj.Get(ACCOUNT, 'Connection',
reply_handler=self.__got_connection_cb,
error_handler=partial(self.__error_handler_cb,
  'Account.GetConnection'))
obj.connect_to_signal(
'AccountPropertyChanged', self.__account_property_changed_cb)


When connecting to ad-hoc, "AccountPropertyChanged" is never emitted, as it
happens in other scenarios.


> There is no /usr/libexec/telepathy-salut process.  The process does
> exist i

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[James Cameron]

On Tue, Sep 16, 2014 at 02:14:56PM -0400, Martin Abente wrote:
> James, Gonzalo,
> 
> Regarding the IBSS/Ad-hoc scenario, if I set the address manually,
> collaborations work just fine. So this must be related to network
> discovery.

Thanks, that's interesting.  Can you tell me _how_ you set the address
manually?  When I tried it there was no real difference:

http://wiki.laptop.org/go/User:Quozl/Fedora_20/Manual_network_configuration

> My test goes like this:
> 
> * I use one XO with fc18+S0.100 to create an ad-hoc network network.
> * From another XO, with fc20+S0.102, I connect to that ad-hoc network.
> 
> The second XO ip address does not match the first one's network.

Can you tell me how it does not match?  It always matches when I try
it; a link-local address 169.254.x.x valid to RFC 3927 is always
assigned, as shown by "ip addr" command.

http://en.wikipedia.org/wiki/Link-local_address

> But when I manually configure it, then buddy icons appears and
> collaboration works... 

When I enable Sugar debugging and use sugar-launch as before, a new
interesting message is seen, "No active connection available" which is
because neither Gabble nor Salut is running.

% SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat

...
1410934106.660510 DEBUG root: Requesting public share of activity 
3b34e9d6ce9f294d12cd79314f7946a2f8845be5.
1410934106.662832 DEBUG root: Share of activity 
3b34e9d6ce9f294d12cd79314f7946a2f8845be5 failed: No active connection available.
...

The error is reported by the __share_cb method of the Activity class.

/usr/lib/python2.7/site-packages/sugar3/activity/activity.py:

def __share_cb(self, ps, success, activity, err):
if not success:
logging.debug('Share of activity %s failed: %s.' %
  (self._activity_id, err))
return

...

def share(self, private=False):
...
pservice = presenceservice.get_instance()
pservice.connect('activity-shared', self.__share_cb)
pservice.share_activity(self, private=private)

The error comes from the share_activity method of the PresenceService
class.

/usr/lib/python2.7/site-packages/sugar/presence/presenceservice.py

def share_activity(self, activity, properties=None, private=True):
...
connection_manager = get_connection_manager()
account_path, connection = \
connection_manager.get_preferred_connection()

if connection is None:
self.emit('activity-shared', False, None,
  'No active connection available')
return

/usr/lib/python2.7/site-packages/sugar/presence/connectionmanager.py

def get_preferred_connection(self):
best_connection = None, None
for account_path, connection in self._connections_per_account.items():
if 'salut' in account_path and connection.connected:
best_connection = account_path, connection.connection
elif 'gabble' in account_path and connection.connected:
best_connection = account_path, connection.connection
break
return best_connection

There is no /usr/libexec/telepathy-salut process.  The process does
exist if an access point is used in place of IBSS ad-hoc.  The
question becomes: why isn't Salut running?

> On Tue, Sep 16, 2014 at 11:01 AM, Martin Abente <[1]
> martin.abente.lah...@gmail.com> wrote:
> 
> Hello James,
> 
> I included the new kernel  (and reverted that commit) and now 
> collaboration
> works even between fc20+S0.102 and F18+S0.100.
> 
> I tested it using a wifi network (with DHCP enabled) and Chat activity.
> 
> Really awesome work James!
> 
> On Tue, Sep 16, 2014 at 3:53 AM, James Cameron <[2]qu...@laptop.org> 
> wrote:
>
> Summary: partially solved with new kernel.
> 
> The Chat activity was run with debug logging in Terminal:
> 
>         % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
> 
> At the time the activity was shared, the log showed:
> 
> 1410842095.436535 DEBUG sugar3.presence.activity: <_ShareCommand 
> object
> at 0x527dc8 (sugar3+presence+activity+_ShareCommand at 0x4f7c20)>: 
> Join
> finished DBusException(dbus.String(u'Failed to connect to multicast
> group'),)
> 
> Telepathy Salut was failing to setup the multicast group, because it
> was calling setsockopt with SO_REUSEPORT, because Fedora 20 header
> files define SO_REUSEPORT, but the OLPC kernel did not.
> 
> (It is bad that the failure was not reported to the user or to the
> logs unless debug logging was turned on.  If someone cares, they can
> raise a bug.)
> 
> Adding SO_REUSEPORT support to the kernel [2] solved for Salut over
> networks where DHCP is available; such as wired or wireless access
> points.  The new kernel is in the dropbox [3].  The previous change to
> avahi-daemo

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Kevin Gordon Gmail]

James, didn't we have an avahi workaround for ‎this kinda thing before in the olden days, where having a simultaneous USB Ethernet and wireless connection  caused self-assigned addresses to mess up the buddy visibility?I may be mis-remembering, or it may have been an unrelated issue, but forgive me, for I  did live a full life in the seventies. :-)Cheers,KG  Sent from my currently functioning gadget  From: Martin AbenteSent: Tuesday, September 16, 2014 14:15To: James CameronCc: XO Laptop Developers; Sugar-dev DevelSubject: Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost worksJames, Gonzalo,Regarding the IBSS/Ad-hoc scenario, if I set the address manually, collaborations work just fine. So this must be related to network discovery.My test goes like this:* I use one XO with fc18+S0.100 to create an ad-hoc network network.* From another XO, with fc20+S0.102, I connect to that ad-hoc network.The second XO ip address does not match the first one's network. But when I manually configure it, then buddy icons appears and collaboration works... On Tue, Sep 16, 2014 at 11:01 AM, Martin Abente  wrote:Hello James,I included the new kernel  (and reverted that commit) and now collaboration works even between fc20+S0.102 and F18+S0.100.I tested it using a wifi network (with DHCP enabled) and Chat activity.Really awesome work James!On Tue, Sep 16, 2014 at 3:53 AM, James Cameron  wrote:Summary: partially solved with new kernel.

The Chat activity was run with debug logging in Terminal:

        % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat

At the time the activity was shared, the log showed:

1410842095.436535 DEBUG sugar3.presence.activity: <_ShareCommand object at 0x527dc8 (sugar3+presence+activity+_ShareCommand at 0x4f7c20)>: Join finished DBusException(dbus.String(u'Failed to connect to multicast group'),)

Telepathy Salut was failing to setup the multicast group, because it
was calling setsockopt with SO_REUSEPORT, because Fedora 20 header
files define SO_REUSEPORT, but the OLPC kernel did not.

(It is bad that the failure was not reported to the user or to the
logs unless debug logging was turned on.  If someone cares, they can
raise a bug.)

Adding SO_REUSEPORT support to the kernel [2] solved for Salut over
networks where DHCP is available; such as wired or wireless access
points.  The new kernel is in the dropbox [3].  The previous change to
avahi-daemon configuration is removed [4].

A different problem occurs with Salut over link local addresses; IBSS
ad-hoc wireless.  The buddy icons are missing.

        # avahi-browse -t _presence._tcp # shows no output

References:

1.
http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/gibber/gibber-multicast-transport.c

2.
http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5

3.
http://rpmdropbox.laptop.org/f20-xo4/
kernel-3.5.7_xo4-20140916.0607.olpc.5196e01.armv7hl.rpm

4.
http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=f34ddb8b83ca6b9cb657e115df117ffa3704eea5


On Thu, Sep 11, 2014 at 06:24:20PM +1000, James Cameron wrote:
> G'day,
>
> Activities shared by Fedora 20 systems do not appear in Network
> Neighbourhood on Fedora 18 or Fedora 20 systems.  Buddies appear.
> Activities shared by Fedora 18 Sugar 0.98 systems appear.
>
> So this is a failure to announce sharing of activities on Sugar 0.102
> on Fedora 20.
>
> tcpdump shows mDNS packets for every operation except when an activity
> is shared on Fedora 20.
>
> avahi-browse output is consistent with Network Neighbourhood.
>
>       avahi-browse -t _presence._tcp # for buddies
>       avahi-browse -t _clique._udp # for activities
>
> (avahi-daemon needed tweaking to compensate for lack of SO_REUSEPORT
> support in 3.5 kernel; change /etc/avahi/avahi-daemon.conf to set
> disallow-other-stacks=yes)
>
> I have tried http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
> but there is no interesting output corresponding to the event.
>
> I have used strace and seen possible D-Bus activity relating to the
> event.  sendmsg(11, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1<\0\0\0/\0\0\0\252\0\0\0\1\1o\0?\0\0\0/org/fre"..., 192}, {"+\0\0\0org.freedesktop.Telepathy.Ch"..., 60}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 252
>
> I welcome any suggestions for further diagnosing this problem.
>
> --
> James Cameron
> http://quozl.linux.org.au/

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

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Martin Abente]

James, Gonzalo,

Regarding the IBSS/Ad-hoc scenario, if I set the address manually,
collaborations work just fine. So this must be related to network discovery.

My test goes like this:

* I use one XO with fc18+S0.100 to create an ad-hoc network network.
* From another XO, with fc20+S0.102, I connect to that ad-hoc network.

The second XO ip address does not match the first one's network. But when I
manually configure it, then buddy icons appears and collaboration works...

On Tue, Sep 16, 2014 at 11:01 AM, Martin Abente <
martin.abente.lah...@gmail.com> wrote:

> Hello James,
>
> I included the new kernel  (and reverted that commit) and now
> collaboration works even between fc20+S0.102 and F18+S0.100.
>
> I tested it using a wifi network (with DHCP enabled) and Chat activity.
>
> Really awesome work James!
>
> On Tue, Sep 16, 2014 at 3:53 AM, James Cameron  wrote:
>
>> Summary: partially solved with new kernel.
>>
>> The Chat activity was run with debug logging in Terminal:
>>
>> % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
>>
>> At the time the activity was shared, the log showed:
>>
>> 1410842095.436535 DEBUG sugar3.presence.activity: <_ShareCommand object
>> at 0x527dc8 (sugar3+presence+activity+_ShareCommand at 0x4f7c20)>: Join
>> finished DBusException(dbus.String(u'Failed to connect to multicast
>> group'),)
>>
>> Telepathy Salut was failing to setup the multicast group, because it
>> was calling setsockopt with SO_REUSEPORT, because Fedora 20 header
>> files define SO_REUSEPORT, but the OLPC kernel did not.
>>
>> (It is bad that the failure was not reported to the user or to the
>> logs unless debug logging was turned on.  If someone cares, they can
>> raise a bug.)
>>
>> Adding SO_REUSEPORT support to the kernel [2] solved for Salut over
>> networks where DHCP is available; such as wired or wireless access
>> points.  The new kernel is in the dropbox [3].  The previous change to
>> avahi-daemon configuration is removed [4].
>>
>> A different problem occurs with Salut over link local addresses; IBSS
>> ad-hoc wireless.  The buddy icons are missing.
>>
>> # avahi-browse -t _presence._tcp # shows no output
>>
>> References:
>>
>> 1.
>>
>> http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/gibber/gibber-multicast-transport.c
>>
>> 2.
>> http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
>>
>> 3.
>> http://rpmdropbox.laptop.org/f20-xo4/
>> kernel-3.5.7_xo4-20140916.0607.olpc.5196e01.armv7hl.rpm
>>
>> 4.
>>
>> http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=f34ddb8b83ca6b9cb657e115df117ffa3704eea5
>>
>>
>> On Thu, Sep 11, 2014 at 06:24:20PM +1000, James Cameron wrote:
>> > G'day,
>> >
>> > Activities shared by Fedora 20 systems do not appear in Network
>> > Neighbourhood on Fedora 18 or Fedora 20 systems.  Buddies appear.
>> > Activities shared by Fedora 18 Sugar 0.98 systems appear.
>> >
>> > So this is a failure to announce sharing of activities on Sugar 0.102
>> > on Fedora 20.
>> >
>> > tcpdump shows mDNS packets for every operation except when an activity
>> > is shared on Fedora 20.
>> >
>> > avahi-browse output is consistent with Network Neighbourhood.
>> >
>> >   avahi-browse -t _presence._tcp # for buddies
>> >   avahi-browse -t _clique._udp # for activities
>> >
>> > (avahi-daemon needed tweaking to compensate for lack of SO_REUSEPORT
>> > support in 3.5 kernel; change /etc/avahi/avahi-daemon.conf to set
>> > disallow-other-stacks=yes)
>> >
>> > I have tried http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
>> > but there is no interesting output corresponding to the event.
>> >
>> > I have used strace and seen possible D-Bus activity relating to the
>> > event.  sendmsg(11, {msg_name(0)=NULL,
>> msg_iov(2)=[{"l\1\0\1<\0\0\0/\0\0\0\252\0\0\0\1\1o\0?\0\0\0/org/fre"...,
>> 192}, {"+\0\0\0org.freedesktop.Telepathy.Ch"..., 60}], msg_controllen=0,
>> msg_flags=0}, MSG_NOSIGNAL) = 252
>> >
>> > I welcome any suggestions for further diagnosing this problem.
>> >
>> > --
>> > James Cameron
>> > http://quozl.linux.org.au/
>>
>> --
>> James Cameron
>> http://quozl.linux.org.au/
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Martin Abente]

Hello James,

I included the new kernel  (and reverted that commit) and now collaboration
works even between fc20+S0.102 and F18+S0.100.

I tested it using a wifi network (with DHCP enabled) and Chat activity.

Really awesome work James!

On Tue, Sep 16, 2014 at 3:53 AM, James Cameron  wrote:

> Summary: partially solved with new kernel.
>
> The Chat activity was run with debug logging in Terminal:
>
> % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
>
> At the time the activity was shared, the log showed:
>
> 1410842095.436535 DEBUG sugar3.presence.activity: <_ShareCommand object at
> 0x527dc8 (sugar3+presence+activity+_ShareCommand at 0x4f7c20)>: Join
> finished DBusException(dbus.String(u'Failed to connect to multicast
> group'),)
>
> Telepathy Salut was failing to setup the multicast group, because it
> was calling setsockopt with SO_REUSEPORT, because Fedora 20 header
> files define SO_REUSEPORT, but the OLPC kernel did not.
>
> (It is bad that the failure was not reported to the user or to the
> logs unless debug logging was turned on.  If someone cares, they can
> raise a bug.)
>
> Adding SO_REUSEPORT support to the kernel [2] solved for Salut over
> networks where DHCP is available; such as wired or wireless access
> points.  The new kernel is in the dropbox [3].  The previous change to
> avahi-daemon configuration is removed [4].
>
> A different problem occurs with Salut over link local addresses; IBSS
> ad-hoc wireless.  The buddy icons are missing.
>
> # avahi-browse -t _presence._tcp # shows no output
>
> References:
>
> 1.
>
> http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/gibber/gibber-multicast-transport.c
>
> 2.
> http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
>
> 3.
> http://rpmdropbox.laptop.org/f20-xo4/
> kernel-3.5.7_xo4-20140916.0607.olpc.5196e01.armv7hl.rpm
>
> 4.
>
> http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=f34ddb8b83ca6b9cb657e115df117ffa3704eea5
>
>
> On Thu, Sep 11, 2014 at 06:24:20PM +1000, James Cameron wrote:
> > G'day,
> >
> > Activities shared by Fedora 20 systems do not appear in Network
> > Neighbourhood on Fedora 18 or Fedora 20 systems.  Buddies appear.
> > Activities shared by Fedora 18 Sugar 0.98 systems appear.
> >
> > So this is a failure to announce sharing of activities on Sugar 0.102
> > on Fedora 20.
> >
> > tcpdump shows mDNS packets for every operation except when an activity
> > is shared on Fedora 20.
> >
> > avahi-browse output is consistent with Network Neighbourhood.
> >
> >   avahi-browse -t _presence._tcp # for buddies
> >   avahi-browse -t _clique._udp # for activities
> >
> > (avahi-daemon needed tweaking to compensate for lack of SO_REUSEPORT
> > support in 3.5 kernel; change /etc/avahi/avahi-daemon.conf to set
> > disallow-other-stacks=yes)
> >
> > I have tried http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
> > but there is no interesting output corresponding to the event.
> >
> > I have used strace and seen possible D-Bus activity relating to the
> > event.  sendmsg(11, {msg_name(0)=NULL,
> msg_iov(2)=[{"l\1\0\1<\0\0\0/\0\0\0\252\0\0\0\1\1o\0?\0\0\0/org/fre"...,
> 192}, {"+\0\0\0org.freedesktop.Telepathy.Ch"..., 60}], msg_controllen=0,
> msg_flags=0}, MSG_NOSIGNAL) = 252
> >
> > I welcome any suggestions for further diagnosing this problem.
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[Gonzalo Odiard]

Thanks James for research and reporting!

On Tue, Sep 16, 2014 at 4:53 AM, James Cameron  wrote:

> Summary: partially solved with new kernel.
>
> The Chat activity was run with debug logging in Terminal:
>
> % SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat
>
> At the time the activity was shared, the log showed:
>
> 1410842095.436535 DEBUG sugar3.presence.activity: <_ShareCommand object at
> 0x527dc8 (sugar3+presence+activity+_ShareCommand at 0x4f7c20)>: Join
> finished DBusException(dbus.String(u'Failed to connect to multicast
> group'),)
>
> Telepathy Salut was failing to setup the multicast group, because it
> was calling setsockopt with SO_REUSEPORT, because Fedora 20 header
> files define SO_REUSEPORT, but the OLPC kernel did not.
>
> (It is bad that the failure was not reported to the user or to the
> logs unless debug logging was turned on.  If someone cares, they can
> raise a bug.)
>
> Adding SO_REUSEPORT support to the kernel [2] solved for Salut over
> networks where DHCP is available; such as wired or wireless access
> points.  The new kernel is in the dropbox [3].  The previous change to
> avahi-daemon configuration is removed [4].
>
> A different problem occurs with Salut over link local addresses; IBSS
> ad-hoc wireless.  The buddy icons are missing.
>
> # avahi-browse -t _presence._tcp # shows no output
>
> References:
>
> 1.
>
> http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/gibber/gibber-multicast-transport.c
>
> 2.
> http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
>
> 3.
> http://rpmdropbox.laptop.org/f20-xo4/
> kernel-3.5.7_xo4-20140916.0607.olpc.5196e01.armv7hl.rpm
>
> 4.
>
> http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=f34ddb8b83ca6b9cb657e115df117ffa3704eea5
>
>
> On Thu, Sep 11, 2014 at 06:24:20PM +1000, James Cameron wrote:
> > G'day,
> >
> > Activities shared by Fedora 20 systems do not appear in Network
> > Neighbourhood on Fedora 18 or Fedora 20 systems.  Buddies appear.
> > Activities shared by Fedora 18 Sugar 0.98 systems appear.
> >
> > So this is a failure to announce sharing of activities on Sugar 0.102
> > on Fedora 20.
> >
> > tcpdump shows mDNS packets for every operation except when an activity
> > is shared on Fedora 20.
> >
> > avahi-browse output is consistent with Network Neighbourhood.
> >
> >   avahi-browse -t _presence._tcp # for buddies
> >   avahi-browse -t _clique._udp # for activities
> >
> > (avahi-daemon needed tweaking to compensate for lack of SO_REUSEPORT
> > support in 3.5 kernel; change /etc/avahi/avahi-daemon.conf to set
> > disallow-other-stacks=yes)
> >
> > I have tried http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
> > but there is no interesting output corresponding to the event.
> >
> > I have used strace and seen possible D-Bus activity relating to the
> > event.  sendmsg(11, {msg_name(0)=NULL,
> msg_iov(2)=[{"l\1\0\1<\0\0\0/\0\0\0\252\0\0\0\1\1o\0?\0\0\0/org/fre"...,
> 192}, {"+\0\0\0org.freedesktop.Telepathy.Ch"..., 60}], msg_controllen=0,
> msg_flags=0}, MSG_NOSIGNAL) = 252
> >
> > I welcome any suggestions for further diagnosing this problem.
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>



-- 
Gonzalo Odiard

SugarLabs - Software for children learning
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[James Cameron]

Summary: partially solved with new kernel.

The Chat activity was run with debug logging in Terminal:

% SUGAR_LOGGER_LEVEL=debug sugar-launch org.laptop.Chat

At the time the activity was shared, the log showed:

1410842095.436535 DEBUG sugar3.presence.activity: <_ShareCommand object at 
0x527dc8 (sugar3+presence+activity+_ShareCommand at 0x4f7c20)>: Join finished 
DBusException(dbus.String(u'Failed to connect to multicast group'),)

Telepathy Salut was failing to setup the multicast group, because it
was calling setsockopt with SO_REUSEPORT, because Fedora 20 header
files define SO_REUSEPORT, but the OLPC kernel did not.

(It is bad that the failure was not reported to the user or to the
logs unless debug logging was turned on.  If someone cares, they can
raise a bug.)

Adding SO_REUSEPORT support to the kernel [2] solved for Salut over
networks where DHCP is available; such as wired or wireless access
points.  The new kernel is in the dropbox [3].  The previous change to
avahi-daemon configuration is removed [4].

A different problem occurs with Salut over link local addresses; IBSS
ad-hoc wireless.  The buddy icons are missing.

# avahi-browse -t _presence._tcp # shows no output

References:

1.
http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/gibber/gibber-multicast-transport.c

2.
http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5

3.
http://rpmdropbox.laptop.org/f20-xo4/
kernel-3.5.7_xo4-20140916.0607.olpc.5196e01.armv7hl.rpm

4.
http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=f34ddb8b83ca6b9cb657e115df117ffa3704eea5


On Thu, Sep 11, 2014 at 06:24:20PM +1000, James Cameron wrote:
> G'day,
> 
> Activities shared by Fedora 20 systems do not appear in Network
> Neighbourhood on Fedora 18 or Fedora 20 systems.  Buddies appear.
> Activities shared by Fedora 18 Sugar 0.98 systems appear.
> 
> So this is a failure to announce sharing of activities on Sugar 0.102
> on Fedora 20.
> 
> tcpdump shows mDNS packets for every operation except when an activity
> is shared on Fedora 20.
> 
> avahi-browse output is consistent with Network Neighbourhood.
> 
>   avahi-browse -t _presence._tcp # for buddies
>   avahi-browse -t _clique._udp # for activities
> 
> (avahi-daemon needed tweaking to compensate for lack of SO_REUSEPORT
> support in 3.5 kernel; change /etc/avahi/avahi-daemon.conf to set
> disallow-other-stacks=yes)
> 
> I have tried http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
> but there is no interesting output corresponding to the event.
> 
> I have used strace and seen possible D-Bus activity relating to the
> event.  sendmsg(11, {msg_name(0)=NULL, 
> msg_iov(2)=[{"l\1\0\1<\0\0\0/\0\0\0\252\0\0\0\1\1o\0?\0\0\0/org/fre"..., 
> 192}, {"+\0\0\0org.freedesktop.Telepathy.Ch"..., 60}], msg_controllen=0, 
> msg_flags=0}, MSG_NOSIGNAL) = 252
> 
> I welcome any suggestions for further diagnosing this problem.
> 
> -- 
> James Cameron
> http://quozl.linux.org.au/

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Telepathy Salut on Sugar 0.102 on Fedora 20 almost works

[James Cameron]

G'day,

Activities shared by Fedora 20 systems do not appear in Network
Neighbourhood on Fedora 18 or Fedora 20 systems.  Buddies appear.
Activities shared by Fedora 18 Sugar 0.98 systems appear.

So this is a failure to announce sharing of activities on Sugar 0.102
on Fedora 20.

tcpdump shows mDNS packets for every operation except when an activity
is shared on Fedora 20.

avahi-browse output is consistent with Network Neighbourhood.

avahi-browse -t _presence._tcp # for buddies
avahi-browse -t _clique._udp # for activities

(avahi-daemon needed tweaking to compensate for lack of SO_REUSEPORT
support in 3.5 kernel; change /etc/avahi/avahi-daemon.conf to set
disallow-other-stacks=yes)

I have tried http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
but there is no interesting output corresponding to the event.

I have used strace and seen possible D-Bus activity relating to the
event.  sendmsg(11, {msg_name(0)=NULL, 
msg_iov(2)=[{"l\1\0\1<\0\0\0/\0\0\0\252\0\0\0\1\1o\0?\0\0\0/org/fre"..., 192}, 
{"+\0\0\0org.freedesktop.Telepathy.Ch"..., 60}], msg_controllen=0, 
msg_flags=0}, MSG_NOSIGNAL) = 252

I welcome any suggestions for further diagnosing this problem.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel