Hi all,
I'm working on fixing up the FreeBSD ath codebase, both for new 11n
chipsets and older chipsets that ath5k supports.
I've noticed something strange with the AR5213. (I don't have any
AR5212 chips or variants thereof.) It happens on MIPS, not on i386. It
doesn't happen with exactly the same software when using an AR9160.
For broadcast packets sent w/ WPA encryption, matching a keycache
entry, I see corruption which always begins in the packet half-way
through the IV word. So, the first four bytes of the IV are fine, but
everything after byte 5 (and the payload) are corrupt.
After the first group rekeying from hostap, the problem rights itself.
If I disable hardware encryption (which still uses keycache entries,
they're just "clear" entries), I still see the packet corruption until
the first group rekey.
If I then disable the keyid on packets sent w/ a group key, the
packets are correctly TX'ed verbatim.
WEP and OPEN are fine.
Has anyone seen this behaviour before?
Is there any documentation available on the AR5213 keycache behaviour,
both normal and broadcast? Why would this occur even when it's not
doing hardware encryption? There's a couple of hints in the codebases:
* AR_KEYTABLE_VALID is in the ath9k/ath5k shared code, but from what I
can gather it's involved in packet RX, not TX. Is this right?
* Is the multicast keycache search behaviour briefly touched on here
and there in the codebases for packet TX, RX, or both?
* This comment seems a bit misleading:
/*
* Group key allocation must be handled specially for
* parts that do not support multicast key cache search
* functionality. For those parts the key id must match
* the h/w key index so lookups find the right key. On
* parts w/ the key search facility we install the sender's
* mac address (with the high bit set) and let the hardware
* find the key w/o using the key id. This is preferred as
* it permits us to support multiple users for adhoc and/or
* multi-station operation.
*/
But if I program the hardware with the high bit set in the MAC entry,
then TX packets without a key id set, it doesn't seem to match the
keycache entry and the packet isn't encrypted.
Any/all help and pointers will be very appreciated, thankyou.
Adrian
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
