[ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted

[Benoit PAPILLAULT <benoit.papillault@free.fr>]

Tor Krill a ?crit :
> On Thu, 2010-04-29 at 16:26 +0800, Daniel Yingqiang Ma wrote:
>   
>> This patch indeed improve the link quality of my AP powered by ath9k.
>>
>> It seems there are plenty of this kind of corruptted packet. Any one
>> know it's reason?
>>     
>
> FYI,
>
> This patch, in modified form went into wireless-testing and linux-next a
> few days ago
>
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=3a37495268ab45507b4cab9d4cb18c5496ab7a10
>
> And it indeed fixed a lot of our issues :). Unfortunately we still
> experience failures with ath9k in AP mode with these symptoms.
>
> We lose connectivity on STA side, we still seems to be associated but
> are unable to transfer any data. Any reconnection fails.
>
> A strange observation is that in some/all(?) cases we are able to
> associate using a STA in pure A/G-mode and transfer data. 
>
> If anyone is interested we would gladly provide dumps/debug information
> on this. (Gathering dumps as we speak)
>
> /Tor
>
>   
I'm experiencing the very same : Using an ath9k STA to connect with a 
802.11abg AP is fine (even if it is ath9k in 802.11a/g mode!), but using 
ath9k STA to connect to a 802.11n AP leads to poor performance and after 
some time, it fails to connect even to a 802.11ag AP.... Reloading the 
kernel module and I'm back online.

I have done lots of capture and observed few things :
- BlockAckRequest never show up (I am wondering if they are filtered by 
the monitor code or simply not sent)
- in syslog, I got lots of message like : "phy0: release an RX reorder 
frame due to timeout on earlier frames"
- performance are bad (like 1 or 2 Mbits) even if everything is sent at 
MCS7 (confirmed by minstrel_ht rate control).
- in capture, there is often a 1 .. 3 ms delay with previous frames.

Regards,
Benoit