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