On Friday 07 September 2012 18:15:03 you wrote:
> On Fri, 2012-09-07 at 18:10 +0200, Christian Lamparter wrote:
> > On Friday 07 September 2012 17:55:42 Johannes Berg wrote:
> > > On Fri, 2012-09-07 at 17:47 +0200, Christian Lamparter wrote:
> > > > Won't this totally disable the crypto offload
> > > > capabilities in AP mode?
> > >
> > > Yes, though we could add an nl80211 attribute that
> > > allows hostapd to tell us, and then if it did tell
> > > us we could know and do the right thing here.
> >
> > if we want to do the right thing here, then I guess
> > we should go for another alternative: a rxkey manager
> > of some sorts. So, we delete keys from the firmware
> > context once MFP comes into the game.
>
> That's kinda what I do though, the flag tells you
> (at key installation) whether MFP will be used or
> not. It's just that in the AP case, mac80211 doesn't
> actually know.
Oh no, I mean dynamic reconfiguration of the firmware's
keycache during runtime. But for this, we would need
a way to tell mac80211 when driver wants to delete a key
from the hw/fw cache and when there is room for another
one (Didn't you had a patch for the "we have a empty slot
in the rxkey cache we are not using" case some time ago?
However in this case, we want to tell mac80211 what "exact"
key (by MAC of the peer and key index) we want.)
Of course, I'm well aware of the "amount of work" and the
problems associated with removing and readding keys during
runtime without causing races (or just minor races).
Regards,
Chr
---
Sorry!
--
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
