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-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@lists.laptop.org > [12]http://lists.laptop.org/listinfo/devel > > References: > > [1] mailto:martin.abente.lah...@gmail.com > [2] mailto:qu...@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@lists.laptop.org > [12] http://lists.laptop.org/listinfo/devel -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel