Re: [PATCH 2/2] mac80211: Support tx-hw-crypt with rx-sw-crypt.

[Ben Greear <greearb@candelatech.com>]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com