Some Intrepid wireless testing results

[Tim Gardner]

I've been doing some testing with some of the wireless devices that I
have in my possession in an attempt to sort out which ones work. My
tests are by no means exhaustive, but I wanted to be sure that these
drivers would at least hook up and do _something_ in the usual use case
scenarios. The Access Point that I'm using is a dual band NetGear
WNDR3300 that supports ABG/802.11n, and WPA/TKIP as well as WPA2/AES. So
far I've worked through i4965, i3945, and Broadcom wl. Then I started
testing Atheros 5K and ran into some serious problems. The ath5k driver
consistently fails under relatively light load and does not seem to
recover. I thought I'd better share my thoughts before finishing tests
on the rest of my wireless repertoire because my proposal with regard to
ath5k is going to require one more kernel upload before release.

As much as it pains me to say this, I think the stock 2.6.27 kernel does
not have a functional ath5k driver and should be disabled in the kernel
build. Ultimately, this means support for Atheros wireless is the same
in Intrepid as it was in Hardy.

However, all is not lost. I've been backporting the wireless testing
repository to the Intrepid linux-backports-modules package. Some folks
have reported good success with that version of ath5k, though I have yet
to test it myself, nor have I done extensive testing on other wireless
adapters. I expect that Atheros support will continue to improve, and I
will update LBM when it makes sense.

The root of the problem is that all Atheros 5K adapters have but a few
unique PCI identifiers. However, 2 adapters with the same PCI ID may
have different RF backends. The newer RF2424 backends are not supported
by the released version of madwifi, yet the madwifi driver still gets
loaded (because the PCI ID matches), fails to init the part, bails out
with an error, and leaves the chipset in an inconsistent state such that
the ath5k adapter cannot init the part either, even though it may have
been able to support the newer backend.

In summary, if the kernel ath5k is not built in the kernel, then there
will be no conflicts with madwifi. The LBM version of ath5k gets loaded
before madwifi, so there shouldn't be a conflict since the newer ath5k
has better support for more RF backends then madwifi and should complete
the init successfully.

Comments?

rtg
-- 
Tim Gardner tim.gardner at canonical.com