From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benoit PAPILLAULT Date: Thu, 29 Apr 2010 22:21:27 +0200 Subject: [ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted In-Reply-To: <1272530496.5866.50.camel@tor-desktop> References: <20100331191058.GD18913@lundinova.se> <20100416104850.GA13329@lundinova.se> <20100420082519.GB5288@lundinova.se> <1271754651.14253.112.camel@ranga-desktop> <20100420110657.GH5288@lundinova.se> <20100420113505.GJ5288@lundinova.se> <1272530496.5866.50.camel@tor-desktop> Message-ID: <4BD9EA47.9080505@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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