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" <da...@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: qu...@us.netrek.org [mailto:qu...@us.netrek.org<qu...@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 > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel > >
_______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel