On 01/23/2014 12:19 AM, Johannes Berg wrote:
On Wed, 2014-01-22 at 16:05 -0800, Ben Greear wrote:
+ * @IEEE80211_KEY_FLAG_SW_RX_CRYPT: This flag indicates hardware will not
+ * do any decrypt for received packets, though it may have uploaded
+ * the hardware key to be used for encrypting transmitted frames.
This isn't needed, all you need to do is return 0 from the set_key
callback in the driver, without programming the key into the device. And
then ignore tkip key updates for such a key.
I want and need to program the key into the device so that it can do the
encryption for transmit. But, I need software to do full decryption on
receive.
Ok so the "without programming the key into the device" part was iwlwifi
specific (on TX the key is given explicitly with that device.) However,
the same still applies - just replace that by "without enabling it for
RX" or so.
That is the only way I could get ath10k to do any sort of software crypt,
and in fact, that is the most efficient way to get the features I need
so I might try getting ath9k to support the same mode some day...
I'll be posting ath10k patches to use this soon, but the dark magic
is down in the firmware in this case.
Ok, whatever, what I'm saying is that mac80211 doesn't care about
whether you enabled the key for RX or not if you return 0 from
set_key(). All it cares about it that if you return 0 the key must be
available for TX. You therefore don't need to make any mac80211 changes.
The ieee80211_tkip_decrypt_data method is explicitly checking if the key is uploaded to hardware.
I need it to think that it is not uploaded to hardware as far as that check
is concerned, otherwise packets will not decrypt properly.
There are other places that check that key-uploaded-to-hardware flag,
so I don't think I can just upload the key and then not set that flag?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
