On Wed, Jun 10, 2009 at 9:42 PM, gregor kowski<gregor.kowski@xxxxxxxxx> wrote: > On Tue, Jun 9, 2009 at 7:52 PM, Johannes Berg<johannes@xxxxxxxxxxxxxxxx> 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 -- 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
