Telepathy Salut on Sugar 0.102 on Fedora 20 almost works
Martin Abente
martin.abente.lahaye at gmail.com
Wed Sep 17 16:28:59 EDT 2014
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.lahaye at 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.lahaye at gmail.com> wrote:
>
>> Hello James,
>>
>> On Wed, Sep 17, 2014 at 5:18 AM, James Cameron <quozl at laptop.org> 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 if an access point is used in place of IBSS ad-hoc. The
>>> question becomes: why isn't Salut running?
>>>
>>
>> The process also exists when changing the "IPv4 Settings/Method"...
>>
>>
>>>
>>> > On Tue, Sep 16, 2014 at 11:01 AM, Martin Abente <[1]
>>> > martin.abente.lahaye at 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]
>>> quozl at 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-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.
>>> > [3]
>>> http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/
>>> > gibber/gibber-multicast-transport.c
>>> >
>>> > 2.
>>> > [4]http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
>>> >
>>> > 3.
>>> > [5]http://rpmdropbox.laptop.org/f20-xo4/
>>> > kernel-3.5.7_xo4-20140916.0607.olpc.5196e01.armv7hl.rpm
>>> >
>>> > 4.
>>> > [6]
>>> 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 [7]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\[8]
>>> > 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
>>> > > [9]http://quozl.linux.org.au/
>>> >
>>> > --
>>> > James Cameron
>>> > [10]http://quozl.linux.org.au/
>>> > _______________________________________________
>>> > Devel mailing list
>>> > [11]Devel at lists.laptop.org
>>> > [12]http://lists.laptop.org/listinfo/devel
>>> >
>>> > References:
>>> >
>>> > [1] mailto:martin.abente.lahaye at gmail.com
>>> > [2] mailto:quozl at laptop.org
>>> > [3]
>>> http://code.metager.de/source/xref/freedesktop/telepathy/salut/lib/gibber/gibber-multicast-transport.c
>>> > [4] http://dev.laptop.org/git/olpc-kernel/log/?h=arm-3.5
>>> > [5] http://rpmdropbox.laptop.org/f20-xo4/
>>> > [6]
>>> http://dev.laptop.org/git/projects/olpc-os-builder/commit/?id=f34ddb8b83ca6b9cb657e115df117ffa3704eea5
>>> > [7] http://wiki.sugarlabs.org/go/BugSquad/Telepathy_Debugging
>>> > [8] http://0org.freedesktop.telepathy.ch/
>>> > [9] http://quozl.linux.org.au/
>>> > [10] http://quozl.linux.org.au/
>>> > [11] mailto:Devel at lists.laptop.org
>>> > [12] http://lists.laptop.org/listinfo/devel
>>>
>>> --
>>> James Cameron
>>> http://quozl.linux.org.au/
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20140917/51c88a22/attachment.html>
More information about the Devel
mailing list