[ath9k-devel] ath9k: corrupt frames forwarded to mac80211 as decrypted

[Will Dyson <will.dyson@gmail.com>]

On Thu, Apr 29, 2010 at 2:08 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:

> If I'm not mistaken, I seem to see the same type of behavior on this
> side. I have a AR5008s in both the STA and AP. After a few hours or so
> of association the suddenly refuses to send or recieve, yet remains
> associated. Thereafter, all further association attempts timeout until
> the driver is reloaded (rmmod/insmod) on the STA. After reloading, I
> will be able to reassociate and things will work fine for a few more
> hours.
>
> I'm not sure if this is precisely the same issue that you're
> experiencing (I always pinned this on the STA since reloading the driver
> seems to reset things) but I felt the similarities were too striking not
> to say something. I'd be happy to provide any debugging information
> necessary.

I see this as well whenever I use N mode on my ath9k AP. G-only mode
is completely solid, however.

My AP is a Planex MZK-W04-NU, running openwrt trunk. Ath9k reports
this chipset info on startup:

phy0: Atheros AR9100 MAC/BB Rev:0 AR2133 RF Rev:a1 mem=0xb80c0000, irq=2

My STA is a TPLINK TL-WN861N minipci card, where ath9k reports chipset info of:

phy0: Atheros AR5416 MAC/BB Rev:2 AR2122 RF Rev:81 mem=0xf8bc0000, irq=10

Unfortunately, I do not currently have another N-capable STA to test against.

-- 
Will Dyson