From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jouni Malinen Date: Wed, 10 Feb 2010 12:51:24 +0200 Subject: [ath9k-devel] ath9k in wireless-testing won't work in AP mode In-Reply-To: <20100203000843.GE17797@tux> References: <1264806315.23248.22.camel@mj> <4B63709F.2010805@openwrt.org> <1264880367.26739.25.camel@mj> <4B64922C.1090809@openwrt.org> <1264883839.26739.47.camel@mj> <4B649ABB.1040203@openwrt.org> <20100203000843.GE17797@tux> Message-ID: <1265799084.9095.28.camel@jm-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 Tue, 2010-02-02 at 16:08 -0800, Luis Rodriguez wrote: > We have reviewed this. The 64 value came from interoperability > tests against another 802.11n device which had increased delayed BlockAcks > when CTS-to-self was enabled. Although this is a higher value than > what the standard says to use we recommend to just leave the value as-is > and actually use the values from the initvals as the minimum possible > value as those are the values that have been used for a large array > of tests, including WMM interop tests. We cannot gaurantee proper > functionality against other devices otherwise. Is someone still looking into more details? The current wireless-testing.git state is completely unacceptable and as a quick fix, I can think of two options: 1) revert the patches that introduced the regression (clean up of ACK timeout setting and the new coverage class support (since it depends on the previous one)) or 2) add new code to enforce that the ACK timeout (and CTS timeout, too, I would assume) get set to at least the value from the initvals (i.e., never use smaller values than before). The latter option would mean that the new coverage class support would start kicking in only when the configuration indicates need for longer timeouts than the default values. I don't care too much how this is resolved in short term, but I think that one of the options described above really needs to happen quickly; ath9k in wireless-testing.git has already been more or less completely broken for couple of weeks (at least with some hardware/configuration combinations). > Since the issues so far are obaserved on AR9160 and AR9220 > (and not AR9280) and AR9271 (sujith) this might be a bus issue The current snapshot is very much broken with my AR9280 (at least on 2.4 GHz band) when using AP mode (the assoc resp frame is not reported as ACK'ed). I haven't really looked into the details (and don't really like to do that either ;-), but the part that broke this was the cleanup patch for ACK timeout/slottime setting. It changed the default AR_TIME_OUT value from 0x08400b00 to 0x03440344 (latter half being the ACK timeout) and reverting that makes the AP work again. - Jouni