From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Roskin Date: Sat, 30 Jan 2010 16:11:12 -0500 Subject: [ath9k-devel] ath9k in wireless-testing won't work in AP mode In-Reply-To: <4B649ABB.1040203@openwrt.org> 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> Message-ID: <1264885872.26739.53.camel@mj> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Sat, 2010-01-30 at 21:46 +0100, Felix Fietkau wrote: > > But using the value of 10 instead of 9 for sc->beacon.slottime does the > > trick. That's the minimal patch that works for me. > > > > Perhaps we should be using ATH9K_SLOT_TIME_9 there (see mac.h) and > > define it to 10. > That value would still be wrong, though. According to the 802.11 docs, > the slot time for 2.4 GHz has to be set to 9 usec, not 10. OK, we may need a fudge factor elsewhere. Ideally, it should be based on Atheros documentation, but we cannot just keep the driver in a non-functioning state if we don't have such documentation. > If this is a bug in the hardware, we need to know about the implications > before we pick a value that just happened to work in our tests, but may > not work in all cases. > slottime=9, acktimeout=64 is what the initvals use, so that's tested by > Atheros. If we continue to receive no comments from Atheros on this > issue, we should probably use those values by default. > By the way, 5 GHz seems to be unaffected by this issue, which makes this > a little suspicious. Indeed, it's unaffected. But the reason is because sifstime is 16 for the band, not 10, which pushes acktimeout to 25. I tried setting acktimeout to a lower value. 23 is OK on channel 165, 22 is not. 22 is OK on channel 36 though. -- Regards, Pavel Roskin