Selftest: wlan test - associate and ping

[martin.langhoff]

To exercise the wlan card, and get a better idea of its proper functioning, we could have a new test that associates to a predefined ESSID, obtains an IPv4 lease, and pings the default gateway.

[wmb@…]

Fixed by svn 2553. The test looks for an access point named OLPCOFW, which must be open, and tries to associate with it. Failure to find OLPCOFW is not an error, but if OLPCOFW is found, failure to associate with it is an error.

Since the purpose of the test is to verify that the WLAN transmitter works, and since successful association requires a bidirectional exchange, there is no need to perform the DHCP or ping embellishments. Those additional steps would just add complexity, time, and the possibility of false failures due to server issues. For example, if lots of XOs were being tested, the DHCP server could run out of leases. After successful association, the test disassociates, to free up any access point resources that might be consumed.

scp dev.laptop.org:~wmb/q4b10mq.rom is a test build for XO-1.75 (the feature is in common code that should apply to XO-1 and XO-1.5 given a suitable build).

[Quozl]

Also, the test is done twice if "test /leds" is run, this is an expected side-effect.

[reuben]

The customer would prefer that the test scan for any open SSID and attempt association.

[Quozl]

I think we should separate our manufacturing test from what the customer wants, and make a new test for the customer alone.

While we can reasonably assume that an OLPCOFW SSID can be prevented from occurring during manufacturing, I don't think the same can be said for any open SSID. A laptop running default tests would transmit RF; currently they do not. A set of laptops doing the test will cause interference. Some chance future access point may cause test failure through some mechanism we are not yet aware of.

Once the test is customer specific, we can also add DHCP and ping. However, even that is not an adequate test for some requirements. We should also be attempting large packet length pings, multicast, TCP, UDP, and DNS. We have another kernel that can do all this, without requiring OpenFirmware.

[wmb@…]

What failure mode do you have in mind that would be caught by the extensive suite of tests cited above? It seems to me that extensive tests as described would be susceptible to false positives due to server misconfiguration or other causes unrelated to hardware failure. My philosophy is that the simplest test that catches the expected failure mode is best. The hardware failure mode that I believe we are looking for is transmitter death. That failure would be caught by an association attempt.

[Quozl]

Transmitter partial failure, triggered by long duration of transmission or thermal changes. I don't really know what the customer wants to test for, nor what population of units can associate but can't communicate in other forms. I suspect that population is zero. Reuben can you confirm?

(Yes, the extensive tests would be susceptible to false positives, such as wireless firmware failure. Since we provide the firmware to the device from OpenFirmware, and provide potentially different firmware from Linux, it would be inappropriate to test the wireless firmware in OpenFirmware.)

[wmb@…]

The description of what the customer wants says "we could have a new test" ...

Is it really a "new" test that the customer wants - i.e. a test invoked by a new (and different) command - or does the customer really want the *existing* test (invoked by bare "test /wlan" or the graphical menu) to have the additional functionality?

I would be happy to add the "new test" as defined above, but I'm still uncomfortable with the idea of changing the existing test to - by default - try associating with some random open access point. I just think that is a recipe for false failures that will cause us no end of problems.

martin/reuben - could you find out what sort of manual configuration that the customer would be willing to perform in order to enable this test mode? The possibilities that are available within the confines of existing facilities are:

* Add a manufacturing data tag that turns on this feature * Execute a specific command from the ok prompt, e.g. ok test /wlan:associate * Hold down a key or game button during the execution of the graphical menu command (although this possibility is a bit screwy from a UI perspective, and wouldn't work on XO-3)

[wmb@…]

Still looking for feedback ...

[greenfeld]

Setup an Open AP named OLPCOFW and verified OFW associated with it provided it showed up in the scan (more APs than OFW can show at once are present in the area).

Blacklisted the XO-1.75 with Q4D02 via MAC Address from using this AP and verified that the WLAN selftest failed when OLPCOFW was detected as a AP available in the area {which rejected said XO as a client}.

I'm not certain if I should leave this open to get more customer feedback, or close this.

[Quozl]

Released in Q2F06 and Q3C01. Was already in Q4B11.