From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tor Krill Date: Fri, 30 Apr 2010 11:50:09 +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: <1272621009.2191.61.camel@tor-desktop> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Thu, 2010-04-29 at 10:41 +0200, Tor Krill wrote: > 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) We ran a test again last night, ans sure enough it stopped working after a few hours. Our testsetup is like this: We have a windows, with an intel 5100 wireless adapter, machine running iperf in server mode. This machine connects to our AP, a PPC based NAS with a "Atheros AR9280 Rev:2" minipci card. The system runs linux-next from 20100427 with above mentioned patches. On the LAN attached to the PPC machine above we have a linux PC running iperf client attaching to the iperf server on the windows machine. Them we use a fourth computer that dumps the traffic in the air. An excerpt of the traffic, captured around the failure, can be found here: http://213.88.146.173/logs/krashlog.pcap But when looking into this, with my limited understanding of 802.11, it seems like our AP stops responding for some reason. The STA continues for a while and then gives up. When trying to reassociate noting ever shows up in the daemon logs. The AP apears as to be not getting the received traffic, or it gets stuck some where. Very similar symptoms as we had before. But even though the symptoms seems very much like they did before, our debug information, says that we don't receive any corrupt frames any more. So my conclusion here is that we seem to have further problems with the 80211 stack or maybe more likely ath9k getting stuck under some circumstances. Is there anything else i could do to sched some light on to this issue? /Tor