[Server-devel] Collaboration XO-1 with XS

Sun Apr 29 20:18:01 EDT 2012

I'll do some work when I get a chance to replicate and isolate the issue and
get some data as you suggest.

Quick question, is it possible to transfer the database and Moodle history
(users, etc) from one XS installation to a new one, i.e. effectively to make
a copy..? 

David Leeming

From: Martin Langhoff [mailto:martin.langhoff at gmail.com] 
Sent: Sunday, 29 April 2012 1:45 a.m.
To: David Leeming
Cc: OLPC Devel; XS Devel; James Cameron
Subject: RE: [Server-devel] Collaboration XO-1 with XS

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-1s and
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] 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/devel/attachments/20120430/9ab972c1/attachment.html>