Re: [PATCH] mac80211 : fix a race with update_tkip_key

gregor kowski
2009-06-10T22:17:17Z

On Wed, Jun 10, 2009 at 9:42 PM, gregor kowski<gregor.kowski@gmail.com> wrote:
> On Tue, Jun 9, 2009 at 7:52 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Tue, 2009-06-09 at 19:48 +0200, gregor kowski wrote:
>>
>>> > Right. But drivers are free to even only _encrypt_ tkip frames and never
>>> > _decrypt_ them after having accepted a hardware key, iow that is
>>> > perfectly valid behaviour and I don't think we should keep uploading the
>>> > key to the driver. Worst case is that the proper upload fails and we
>>> > decrypt all frames in software until the next rollover.
>>> >
>>> What's the point of setting the tkip callback if we aren't interested
>>> in decrypting data by hardware ?
>>
>> Might depend on something else? Anyhow I don't see the point of
>> continuing to call the callback. Maybe it should just be part of the key
>> todo instead when the key is initially uploaded to the hw.
>
> Or what do you think about this. This will call the callback only once per wrap.
But this won't work if you want to support QOS.
So how update_tkip_key is supposed to work with QOS (ie different
rx->queue value) and multiple tkip IV ?

BTW did you know why there only one tkip IV on tx and not one per qos queue ?

Gregor