This dates way, way back with the original net80211 support w/ atheros chips.
The earliest chip (AR5210) had limitations supporting software encryption.
It only had the four WEP slots, and not any keycache entries. So when
trying to do CCMP/TKIP encryption would be enabled and the key slots
would have nothing useful in them, resulting in garbage encryption/decryption.
I changed this back in 2012 to disable supporting hardware WEP so it's
all done in software and yes, I could do CCMP/TKIP on AR5210 in software.
Fast-forward to newer-ish hardware - the Qualcomm 11ac hardware.
Those also don't support pass-through keycache slots! Well, the hardware
does at that layer, but then there's a whole offload data path encap/decap
layer that's turning the frames from raw wifi into ethernet frames (for
"dumb" AP behaviours) or "wifi direct" frames (ie, "windows".)
This hides a bunch of header frame contents required for doing the software
encryption / decryption path.
But then if you enable the raw transmit/receive frame format it ALSO
bypasses the hardware encryption/decryption engine!
So for those NICs:
- If you want to do encryption, you can only use the firmware supported ciphers w/ wifi direct or ethernet;
- If you want to use software encrypt/decrypt, you MUST disable all encryption and instead use 100% software encryption.
The wpa_supplicant bsd driver code has a specific comment about this and
flips on supporting WEP/TKIP/CCMP, which is understandable but it doesn't
fix the ACTUAL intention of all of this stuff.
So:
- create a new field, ic_sw_cryptocaps
- populate it with the supported set of ciphers for net80211 (right now wep, tkip, ccmp)
- Communicate that upward to wpa_supplicant via the relevant devcap ioctl.
I'll follow this up with a driver_bsd.c change in wpa_supplicant to
trust this again, and then start adding the other cipher support there.