Comment 12 for bug 1311462

I reproduced the case which
the wireless n is automatically tested and passed
by checkbox 0.16.8 (bzr rev 2294) on 201112-10226.
The wireless n is automatically launched because
it does not require the 80211 n resource in the job file,
say wireless.txt.in.

The requirement of the 80211 resource is added in the bzr rev 2617,
with a timestamp on 14 Jan 27th.
This is consistent with the date of the last submission
which automatically launched and passed the wireless n testing.
Please refer to https://certification.canonical.com/hardware/201112-10226/submissions/

I also tested elder kernels (3.2.0-29-generic, 3.2.0-59-generic for precise)
together with bcmwl-kernel-source (6.20.155.1+bdcom-0ubuntu0.0.2)
'iw phy0 info' doesn't show the HT is supported.
This means the wireless n protocol of the wireless cards
is not supported very well long time ago and
checkbox does not catch that.
The good news is, it could work for some of wirless cards in saucy kernels, please see comment#8.

So, my conclusion is, our checkbox is on the right way.
We have a more robust wireless testing jobs now,
which requires the necessary n protocol resource, than we did before.
Now checkbox catches the bad wirless support.
The wireless modules, mainly broadcom's product, seem not to support very well.
And it may or may not be caused by the driver bcmwl-kernel-source.
It doesn't report to iw there is n protocol support.
Please see comment#8, the chipset supports protocol n by saucy kernel.

I don't think the skipped wireless n testing is a checkbox bug.
Actully this is the correct behavior
when the wireless module support, including kernels, wl kernel module/driver or hardware,
doesn't work very well.
Checkbox should catch the bad support.

I prefer to
* set the status as invalid.
* file a bug report for bcm driver which does not report correct driver info.
* (optional) file a bug for network-manager which may use a n protocol as a g protocol.
* keep our resource requirement. e.g. we don't need to modify our code.