Hi,
I now know why 802.11n receive stalls; ath9k is passing corrupt frames to
mac80211.
The corrupt frames are marked as decrypted so the receive PN is updated to a
random number. Later non-corrupt frames with correct PNs are consequently
deemed out-of-sequence and are dropped. Connection is
Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
incorrectly be marked decrypted (even if key index in frame is valid).
Signed-off-by: Johan Hovold johan.hov...@lundinova.se
---
The current code overrides the hardware flag indicating that the key index is
invalid and falsely mark
Frames tagged by hardware with ATH9K_RX_KEY_MISS should not
incorrectly be marked decrypted.
Signed-off-by: Johan Hovold johan.hov...@lundinova.se
---
The frame below has no error flags set besides KeyMiss and would be marked
decrypted by the current code.
: 88 41 30 00 00 80 48 68 08
Frames tagged by hardware with ATH9K_RX_DECRYPT_BUSY should not
incorrectly be marked decrypted.
Signed-off-by: Johan Hovold johan.hov...@lundinova.se
---
Some corrupt frames such as the one below have DecryptBusyErr flag set even
though frame is marked ok and without DecryptCRCErr set.
Check error flags even if frame is marked ok by hardware as this flag
may have been incorrectly set.
Signed-off-by: Johan Hovold johan.hov...@lundinova.se
---
: 88 41 30 00 00 80 48 68 08 af 00 b9 49 c3 e1 3f
0010: 5a 9d 51 71 09 63 00 50 00 00 00 00 ff 54 00 20
0020: 36 9d 46 02
On Fri, 2010-04-16 at 03:52 -0700, Johan Hovold wrote:
Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
incorrectly be marked decrypted (even if key index in frame is valid).
Have you tested this with static WEP configuration? Or broadcast RX with
WPA? There must be a reason for
maybe I should report to openwrt-devel list, but I think it is the problem
of ath9k, caused by using the module minstrel_ht.
I have the same issue using ath9k/minstrel_ht. I think the problem is due to
the way the streams variable is calculated in minstrel_ht_get_group_idx().
I printed some
