[OLPC New Zealand] [Testing] Testing Summary, Auckland - 21 April 2012

[Tom Parker]

On 25/04/12 02:54, Kevin Gordon wrote:
> In our little test ab we have also experienced some anomalies in the
> neighbourhood view.  We experienced that with certain AP's - after about
> 8 laptops come up and are attached to the WPA2 AP - that the
> neighbourhood view on the laptops no longer consistently or reliably
> shows all of the laptops.

Our testing location provides internet, but we don't know much about 
their network. We'll run some more tests with a more controlled wifi 
environment. We don't normally get more than about 5 or 6 laptops 
running, but maybe their network is weak.

> Unfortunately, this symptom seems to appear only on our TP-link running
> Open WRT and our Buffalo running DD-WRT.  The view shows all 20 of the
> laptops when we use our Cisco or Cradlepoint AP's - both of which are
> running their proprietary firmware.

We are involved with a 1-1 laptop deployment in New Zealand and all the 
advice has been that you need to spend a lot of money on heavy duty 
access points. They're using Ruckus with good results, but one school 
joked that they could buy a cheap access point for each and every 
student with the money they spent on their Ruckus system.

> We have a tech volunteer here who
> is investigating whether there might be a setting within the open-source
> firmware for the TP-Link and Buffaloes that might better be able to
> handle these items.    One theory he is exploring is whether the AP is
> fracking the multicast.

Have you tried without any encryption? WPA encryption has some 
interesting effects on station-station communications.

> However, we have no experimental proof as to
> the real cause yet.

Are you familiar with tcpdump? You can use tcpdump to compare what is 
sent and received on different laptops. You may be able to run tcpdump 
on the OpenWRT or DD-WRT access points too. I've found that putting the 
network interface into promiscuous mode on an XO prevents the laptop 
from receiving anything so you have to turn that option off (you don't 
want it on, at least initially anyway, since the OS won't see packets 
that would normally be filtered out on the hardware).

The following will print a line for each packet:

tcpdump -p -i eth0

The following will write a file which you can examine in wireshark (you 
may want to view the timestamps as absolute time if you're comparing 
more than one trace):

tcpdump -p -s 0 -i eth0 -w dump.pcap

> Perhaps also of interest is that all 20 also show up perfectly in the
> neighbourhood view if we use ad-hoc instead of the AP, ,as they are
> powered up one after the other.  Also, for this test, we are running
> these machines all at build 883, so and they are a mix of 1.0s and
> 1.5s.  So, for us, this symptom is neither F17 not 1.75 dependent.  We
> have also found that deleting the network history before each test
> invocation helps to not have a 'moving target'.

How do you delete the network history?

> Further, we have done no testing on collaboration, at present we are
> just looking longingly at the pretty screen of neighbourhood view , in
> these various AP environments, since our present goal is to select a
> robust , yet affordable, AP.

We have heard mixed reports about whether the neighbourhood view is 
supposed to work reliably :( What is the expected behaviour in recent 
releases?