From: Christian Lamparter <chunkeey@googlemail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Dan Williams <dcbw@redhat.com>,
linux-wireless@vger.kernel.org, linville@tuxdriver.com
Subject: Re: [PATCH v2] p54: connect to 11w protected networks
Date: Fri, 7 Sep 2012 18:26:58 +0200 [thread overview]
Message-ID: <201209071826.59089.chunkeey@googlemail.com> (raw)
In-Reply-To: <1347034503.4256.31.camel@jlt4.sipsolutions.net>
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!
next prev parent reply other threads:[~2012-09-07 16:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-02 13:22 [PATCH] p54: connect to 11w protected networks Christian Lamparter
2012-09-02 21:48 ` Johannes Berg
2012-09-04 13:19 ` [PATCH v2] " Christian Lamparter
2012-09-04 14:15 ` Johannes Berg
2012-09-04 14:33 ` Dan Williams
2012-09-04 14:37 ` Johannes Berg
2012-09-04 14:54 ` Johannes Berg
2012-09-07 12:17 ` Johannes Berg
2012-09-07 15:47 ` Christian Lamparter
2012-09-07 15:55 ` Johannes Berg
2012-09-07 16:10 ` Christian Lamparter
2012-09-07 16:15 ` Johannes Berg
2012-09-07 16:26 ` Christian Lamparter [this message]
[not found] ` <201209071825.13588.chunkeey@googlemail.com>
[not found] ` <1347035277.4256.33.camel@jlt4.sipsolutions.net>
2012-09-07 17:01 ` Christian Lamparter
2012-09-07 17:09 ` Johannes Berg
2012-09-07 17:28 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201209071826.59089.chunkeey@googlemail.com \
--to=chunkeey@googlemail.com \
--cc=dcbw@redhat.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).