Hi,

I noticed that the AR5210 NIC I have here wasn't associating to WPA
networks. Now, the AR5210 only implements WEP (and clear!) so it
should be punting the non-WEP frames to the net80211 stack for
software encryption/decryption handling.

However, it was erroring out. The net80211 stack was getting an error
from the driver whenever it tried installing an encryption key via
drv_key_set().

After hunting around a bit, I discovered:

* There's a driver flag - sc_hasclrkey - which only gets used in some
older code pathway;
* net80211 directly calls a driver method to set an encryption key -
and this calls ath_key_set();
* .. and ath_key_set() doesn't check whether sc_hasclrkey is 1 or not;
it just quite happily tries to program in a CLR key to the AR5210;
* .. then the AR5210 HAL keycache code would error out, as it only
knows about WEP keys.

After fixing that up, I discovered the hardware was returning invalid
looking frames. Ie, they didn't at all match what was going on in the
air.

Then it dawned on me - since CCMP frames also have the WEP bit set in
the header, the hardware was trying to decode them using the WEP keys!

Once I disabled all of the hardware encryption/decryption handling,
the AR5210 can now successfully associate to my 802.11n access points
(protected, of course, with WPA2 + AES-CCMP.)

Now, the hacky patch is here:

http://people.freebsd.org/~adrian/ath/20121118-ar5210-hack-to-enable-non-wpa-crypt.diff

I post this mostly so I don't forget (and I'll file a bug soon about
it) - but the patch disables hardware encryption entirely on the
AR5210. If you then try to use WEP, it'll assume the hardware
encryption is enabled and it'll all quite happily fail.

So if someone's after a bit of an introductory ath/hal project, I'd
love to find a way to tidy this up and make it generic enough to
enable hardware encryption for WEP, but disable hardware encryption
(and do software encryption) for non-WEP. Even if that just ends up
disabling hardware encryption for the AR5210, I could live with that.
But there has to be a slightly cleaner way to do it.



Adrian
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to