Hello James, On Wed, Sep 17, 2014 at 5:18 AM, James Cameron <qu...@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.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