12757

OLPC has identified and fixed a problem with the wireless driver on the XO-1, XO-1.5, XO-1.75 and XO-4 laptops.

Problem

Wireless networks are not shown in network neighbourhood, or take a long time to be shown, or disappear, which prevents use of the network.

On XO-4 (8787), the problem does not occur.

On XO-4 (8686), XO-1.75. and XO-1.5, the problem is more likely as the number of hidden networks increases, becoming especially obvious once there are many more hidden networks than normal networks. A cell phone hosted hidden network carried into a classroom by an adult may induce the symptom.

On XO-1, the problem is more likely as the number of XO-1 laptops in a room increases, becoming especially obvious at around 10 laptops.

Solution

Install one of the fixed kernels below. This solution will be included in any future release of OLPC OS. For earlier releases of OLPC OS, please upgrade.

XO-4

not yet available

XO-1.75

not yet available

XO-1.5

For OLPC OS 13.2.0 on XO-1.5, start the Terminal activity and type this:

wget http://dev.laptop.org/~quozl/12757/kernel-3.3.8_xo1.5-20140212.1212.olpc.e98f01a.i686.rpm
sudo rpm -U kernel-3.3.8_xo1.5-20140212.1212.olpc.e98f01a.i686.rpm
rm kernel-3.3.8_xo1.5-20140212.1212.olpc.e98f01a.i686.rpm
sudo reboot

XO-1

For OLPC OS 13.2.0 or 12.1.0 on XO-1, start the Terminal activity and type this:

wget http://dev.laptop.org/~quozl/12757/kernel-3.3.8_xo1-20140212.0718.olpc.e98f01a.i686.rpm
sudo rpm -U kernel-3.3.8_xo1-20140212.0718.olpc.e98f01a.i686.rpm
rm kernel-3.3.8_xo1-20140212.0718.olpc.e98f01a.i686.rpm
sudo reboot

Workaround

If the solution cannot be applied, there are two alternate workarounds:

• On an affected laptop, repeat the scan using Terminal until the access point appears:

sudo iwlist eth0 scan

• Disable all hidden networks. Disable mesh on all laptops within 300m. This may be impractical for some deployments, since mesh is often useful.

Diagnosis

XO-1.5, XO-1.75, and XO-4: hidden network probe responses arrive at the XO during a scan, may cause the loss of scan results for networks that responded later.

XO-1: mesh probe responses that are sent by other XO-1s, and arrive at an XO-1 during a scan, cause the loss of scan results for access points that responded later. As the number of XO-1 laptops increases relative to the number of access points, the probability of failure increases. With one access point and nine XO-1 laptops the probability of failure can be as high as 90%.

The probability of failure also depends on the collision detection backoff, which may depend on the MAC address of the access point.

Verification

Enable scan debugging and watch the kernel messages:

sudo su
echo 0x80 > /sys/module/libertas/parameters/libertas_debug
cat /proc/kmsg

Perform a scan. Check if the message scan response: invalid IE fmt is shown. The message only appears if the problem occurs.

Credits

• a microdeployment in Haiti,
• a deployment in Nepal,
• Terry Gillett of the Village Telco project for trying to figure out which access point models would work, only to find that any access point may not work,
• James Cameron of OLPC, for finding the problem and fixing it,
• Tim Moody for testing,

See Also

• a call for testing,
• ticket #12757,
• the kernel patch for XO-1, XO-1.5, and XO-1.75.