[Server-devel] Collaboration XO-1 with XS
martin.langhoff at gmail.com
Sat Apr 28 11:44:30 EDT 2012
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
On Apr 28, 2012 5:14 AM, "David Leeming" <david at leeming-consulting.com>
> 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
> 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
> 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
> Devel mailing list
> Devel at lists.laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel