Hi James,
These are valuable statistics.
Does it matter if the xo has previously connected to the ap and stored
connection info? Could we avoid the scan by pre-populating the connection
info? (I think you did this in tinycore. This would also eliminate the
variable of relying on NN to show us the AP.)
Since we are regularly reflashing, could we turn off mesh and prepopulate a
connection to a standard SSID; in Haiti we used 'lekol'? I have the
impression that mesh must be turned off at each boot, so we would need to
add something in the boot process. Can you recommend the best place to do
this.
If this strategy increases the likelihood of connection would it be possible
to get fancier and have our boot script check for a connection to the known
ap and if not found turn mesh back on?
Tim
-----Original Message-----
From: James Cameron
Sent: Friday, February 07, 2014 8:16 PM
To: xsce-de...@googlegroups.com
Cc: server-devel ; OLPC Devel
Subject: [XSCE] Re: Large groups of XO-1 do not work with access points
There seems to be a lot of speculation, so I'll add more technical
details on what Terry and I have been investigating.
1. sometimes, an active scan by the XO-1 does not have the access
point listed in the scan results, despite the XO-1 transmitting an
acknowledgement to the access point,
2. an active scan by the XO-1 is done only twice during boot before
Sugar starts, and is repeated every 30 seconds,
3. if these two active scans do not contain the access point, Sugar
waits 10 seconds before it decides that we don't have any access point
available, and commits to using mesh.
Therefore all it takes is for two active scans to miss the access
point. This can be easily reproduced with "sudo iwlist eth0 scan" and
looking at the "Last beacon" time for the access point.
--
The probability of failure in step 1 has considerable variance across
the test populations. Here are some determinants:
a. the probability varies by access point, even the same model access
point with the same firmware. We see an extreme variation across
access points. I see 5%, 23% and 32% with unused XO-1. Terry sees
worse with his used XO-1 stock.
b. the probability is higher if mesh is enabled in the firmware; my
32% fail rate drops down to 5.8% by turning off mesh using lbs_mesh,
and making no other changes.
c. the probability is higher if many XO-1 are present and connected.
d. the probability is higher if antennas or coax are broken (because
the two antennas are used at different times).
e. the probability is much higher if there are other access points
present on the same channel at some distance.
f. the probability is unchanged with or without encryption, with or
without power limits on the access point, and with or without 802.11n
enabled.
I'm interested to know if anybody has any ideas as to what else to
vary in the experiments.
The test method is to place "sudo iwlist eth0 scan" in a loop, with a
five second repeat cycle, and count the number of scans where a
previous scan result was used. Here's an example test:
--
#!/bin/bash
MA=5C:63:BF:D8:F6:C0
while true; do
T0=$(date +%s)
if [[ $(( $T0 % 5 )) != 0 ]]; then
sleep 0.1
continue
fi
R0=$(sudo iwlist eth0 scan 2>/dev/null | awk "BEGIN{x=0;m=1}
/$MA/{x=1;m=0} /Last beacon/{gsub(\"ms\",\"\"); if (x) print \$4} /IE:
Unknown/{x=0} END{if(m) print \"missed\"}")
if [[ "$R0" == "missed" ]]; then
echo missed
sleep 3
continue
fi
echo $T0 $R0
echo $T0 $R0 >> scan.log
sleep 3
done
--
To generate the percentage failure:
awk 'BEGIN {p=0;f=0} { if ($2 > 1000) { f++ } else { p++ } } END { print p,
f, f * 100 / p }' scan.log
--
Sig inserted by AutoHotkey ver. 1.1.11.01 (signature - first line)
WLMail QuoteFix -> http://www.dusko-lolic.from.hr/ (signature - second line)
_______________________________________________
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
