[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[Felix Fietkau <nbd@openwrt.org>]

On 2010-01-30 9:37 PM, Pavel Roskin wrote:
> On Sat, 2010-01-30 at 21:10 +0100, Felix Fietkau wrote:
> 
>> The workaround value of '64' is actually wrong. When I had trouble
>> associating in 2.4 GHz in a case where the slot time was actually set
>> correctly, I simply used it, because that's what was being set in the
>> initvals. We shouldn't base the slot time on this though - the initvals
>> don't do this either.
> 
> I could reduce the minimal value of acktimeout from 64 to 20.  With 20,
> I get a reliable communication every time.  With 19, it's doesn't work
> ever.  The distance between STA and AP is about 1 meter.
> 
>> The slottime == -1 thing is obviously a bug, and I'll send a patch to
>> fix it later.
> 
> It turns out that simply increasing the initial value to 54 is not
> enough, as ah->slottime will be set to 9 from sc->beacon.slottime, so
> acktimeout becomes 19.
That's why my patch forces it to a minimum of 64 just before it gets set.

> 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.
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.
I've Cc'd Luis, maybe he can forward this to the right people.

- Felix