Testing ath9k
In order to stay up to date with ath9k linux driver, I decided to test it on a laptop. I have used an AR5418 (MB72) miniPCI card for this test and wireless-testing kernel (v2.6.32-rc7-43014-g505f756). I wanted to use this card in order to monitor 802.11n networks. Here is the result.
First of all, you need to create a monitor interface with :
# iw phy phy0 interface add mon0 type monitor
Then, you need to select the proper channel, using the ht40 syntax in order to be able to see 802.11n packets with HT rates :
# iw dev mon0 set channel 100 ht40+
At this point, the meaning of ht40+ versus ht40- is not clear. Of course, it says that you need to use 40 MHz of frequency bandwidth, but it does not tell you which combination is valid and what exact frequency space is used.
Then, we just need to run wireshark on the new interface and we should be fine. However, received packets are not properly unpadded. Padding is something done by hardware in general. It might be more efficient to align some piece of data on a 4 bytes boundary for instance. This is the case with wireless hardware and the 802.11 data. But since 802.11 data is after the 802.11 header, it might be necessary to add 2 bytes between them. This is called padding. Since the hardware does this, the software driver needs to do exactly the opposite. Since each wireless hardware might be doing a different hardware padding, each wireless drivers needs to do a different software unpadding. Here is the patch that fix it : ath9k: This patch fix RX unpadding for any received frame.
Next, we tried this card in station mode, like any ordinary wireless card. We only test with common 802.11g AP. The card has been working fine except on one point : from time to time, ping is stuck for several seconds. After analyzing the traffic with an Open AP and a Zydas USB card, we found out that ICMP request that got lost had the PowerSave bit on! A quickfix for this issue is to disable PowerSave :
# iwconfig wlan0 power off
Once fixed,we were able to send at 20 Mbits on channel 1 (2412 MHz). This is quite good. We now need to test with 802.11n rates (called HT rates).