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 <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