[Server-devel] Collaboration XO-1 with XS

[Martin Langhoff]

When the problem happens, it'll be interesting to see the output of
olpc-netstatus and olpc-xos cmdline utilities on XOs that have trouble and
on those that don't.

There's additional debugging info you can get from ejabberd on the XS.

There's a page in the wiki (in the XS techniques page?) that lists all the
debugging/diagnostics steps for collaboration.

What James mentions is correct, too. A reconnection is what is probably
"fixing" it.

hth,

m
On Apr 28, 2012 5:14 AM, "David Leeming" <david at leeming-consulting.com>
wrote:

> **
>
> Hi James,
>
> I have been fairly familiar some time with using the basic default
> installation of the XS. It is specifically the combination of XO-1 build
> 883 / Sugar 0.94.1 with XS0-0.6 which has thrown up some issues - with
> collaboration.
>
> A typical situation when we observe this recently: a workshop with 20
> teachers, all who have freshly installed release 11.3.0 on their XO-1sand registered on the workshop XS and restarted. All have been accessing
> the Moodle pages with no problems and the links to the public content in
> the /library folder. I will have been using the XS network wirelessly to
> an XO that is running Classroom Broadcast Activity, with no difficult
> whatsoever. So there is no need to ping the server to understand that the
> XOs are all properly connected and registered, although I take your point
> and would have done more diagnostics if i knew how to isolate the issue
> with the collaboration problem we experienced.
>
> We were able to replicate the issue on identically set-up servers. The
> issue is: not all the other connected XOs appear in the neighbourhood
> view, and when trying to demonstrate collaboration using the set up above,
> it was only rarely that the "sharing" icon appeared on other XOs
> neighbourhood view even though all else seemed to be working fine. I
> tried using the discard network history with a few XOs only once at the
> end of the workshop, and we then run out of time. I tried again with my
> own setup later, using two XOs only, and replicated the issue but the
> discard history did not work then. So that might not be useful
> information.
>
> Perhaps I should rephrase my question:
>
> Was it intended that collaboration should work with XO-1s running release
> 11.3.0 using the XS-0.6 default installation?
>
> Secondary question, if this is not working, and I have made no
> customisation other than add some links using aliases presented as links
> on the Moodle home page, what can I do to trouble shoot?
>
> David Leeming
>
> -----Original Message-----
> From: quozl at us.netrek.org [mailto:quozl at us.netrek.org<quozl at us.netrek.org>]
> On Behalf Of James Cameron
> Sent: Friday, 27 April 2012 7:39 a.m.
> To: David Leeming
> Cc: 'XS Devel'; 'OLPC Devel'
> Subject: Re: [Server-devel] Collaboration XO-1 with XS
>
> On Fri, Apr 27, 2012 at 06:38:00AM +1000, David Leeming wrote:
>
> > [...] we work around it by for instance using ?discard network
>
> > history? which seems to help.
>
> I was deeply involved in the "discard network history" feature at one
>
> point in development, and at the time the only thing it did was to
>
> remove access point names (ESSIDs) from the list of known access points.
>
> I've just checked the code and that is still only what it does.
>
> So I'm surprised it is having an effect.  But congratulations for
>
> finding it does have an effect.
>
> I know nothing about the network at the location.  Is there more than
>
> one access point name available?
>
> If so, at the time of the problem, the reason the button is having an
>
> effect may be because a disconnection has led to the laptop associating
>
> with another access point, and pressing the button would prevent that.
>
> If not, then the button is only serving to disconnect the laptop from
>
> the network.  You may find the same effect to occur by clicking on the
>
> access point in the network neighbourhood view.
>
> Lastly, whether activities are open at the time of the forced disconnect
>
> and reconnect may be interesting.
>
> Next time, please do some technical diagnosis at the time of the problem
>
> ... use Terminal activity to ping the server.  As I have recently seen
>
> examples of TP-Link with OpenWRT access points that silently block data
>
> flow, it reminds me that some diagnosis is worth doing.  In the cases I
>
> observed, data flow was restored by reconnecting.  That you currently
>
> reconnect to work around the problem may be a coincidence, or it might
>
> be this same kind of problem.
>
> --
>
> James Cameron
>
> http://quozl.linux.org.au/
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20120428/99bc241e/attachment.html>