Looking through wpa_supplicant and then through the kernel I notice that
we currently in the kernel special-case some things in SIOCSIWAUTH, for
example IW_AUTH_WPA_VERSION is ignored since we rely on the IE that wpa
supplicant gave us.
Apart from how wrong I think this is (we shouldn't be allowing a setting
we can't do, we need to return some error code and wpa_supplicant should
sort it out) I also found only one occurrence in prism54 where the
parameters are actually not ignored. Is that driver fully replaced by
p54?
Is there any point in supporting these at all? Does the Libertas 8388
requires the settings as well instead of just the IE to include?
I'm inclined to just require userspace to put both the IE and the
individual settings into the relevant nl80211 messages, but then we
might just as well piece the IE together from those settings, no?
johannes
On Wed, Mar 28, 2007 at 12:34:06AM +0200, Johannes Berg wrote:
> Looking through wpa_supplicant and then through the kernel I notice that
> we currently in the kernel special-case some things in SIOCSIWAUTH, for
> example IW_AUTH_WPA_VERSION is ignored since we rely on the IE that wpa
> supplicant gave us.
Use of WPA/RSN IE vs. individual parameters depends on the driver. For
example, NDIS drivers generate the IEs internally and need to be
configured with the key management (WPA-PSK, WPA-Enterprise, WPA2-PSK,
WPA2-Enterprise, ..) and cipher suites separately. They would not use
WPA/RSN IE at all. Some drivers use the IE so that kernel code does not
need to have all the code for generating it. They may (or may not,
depending on needs) ignore the individual values.
> Apart from how wrong I think this is (we shouldn't be allowing a setting
> we can't do, we need to return some error code and wpa_supplicant should
> sort it out) I also found only one occurrence in prism54 where the
> parameters are actually not ignored. Is that driver fully replaced by
> p54?
Those two options are there for a reason and which one will be used will
depend on the driver. At the moment, wpa_supplicant does not really like
the error code, but if I remember correctly, it will, in practice), try
to continue associating anyway and the only problem is a bit confusing
output in debug log. Returning -EOPNOTSUPP for parameters that are not
used should be fine.
> Is there any point in supporting these at all?
Yes.
> I'm inclined to just require userspace to put both the IE and the
> individual settings into the relevant nl80211 messages, but then we
> might just as well piece the IE together from those settings, no?
As long as the information is available for the driver at the time of
association request, it does not really matter how that information got
there..
--
Jouni Malinen PGP id EFC895FA
On Wed, 2007-03-28 at 11:04 +0100, Mark Powell wrote:
> > Putting the IE there has the advantage that you can easily play with new
> > things for cards that use the IE by sticking a few more IEs into the
> > attribute.
> I agree. Forming the MLME requests, including the IE, is really the role
> of the userland app (the SME in IEEE802.11 speak).
Right.
> > But it has the disadvantage that cards behave differently if
> > you give them contradictory settings. Maybe we need a way to ask a card
> > which one it wants.
> Is that just a case of garbage-in-garbage-out?
Yes, but I can just see it coming that the developer has a fullmac card
that accepts having no IE and then some users with a halfmac card that
needs the IE present is going to crap out. It'd be nice if we could
avoid that, but I think we probably can't without much overhead that we
don't want.
johannes
Johannes Berg wrote:
> Looking through wpa_supplicant and then through the kernel I notice that
> we currently in the kernel special-case some things in SIOCSIWAUTH, for
> example IW_AUTH_WPA_VERSION is ignored since we rely on the IE that wpa
> supplicant gave us.
>
FWIW we currently use the value of IW_AUTH_WPA_VERSION to generate the
correct cipher suite selector when forming the set-key request for our
hard MAC device. We use other IW_AUTH settings too.
> ...
>
> I'm inclined to just require userspace to put both the IE and the
> individual settings into the relevant nl80211 messages, but then we
> might just as well piece the IE together from those settings, no?
>
We certainly need the individual settings. It is nice that
wpa_supplicant generates the IE - it saved me writing the code - but
that's just being lazy. We still have to modify the IE anyway to add WMM
stuff.
Mark
--
Mark Powell mailto:[email protected]
Group Leader, Host Drivers Tel: +44 (0)1223 692000
CSR, Business Park, Cowley Road, Cambridge, CB24 0WZ, UK
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
On Wed, 2007-03-28 at 00:34 +0200, Johannes Berg wrote:
> Looking through wpa_supplicant and then through the kernel I notice that
> we currently in the kernel special-case some things in SIOCSIWAUTH, for
> example IW_AUTH_WPA_VERSION is ignored since we rely on the IE that wpa
> supplicant gave us.
>
> Apart from how wrong I think this is (we shouldn't be allowing a setting
> we can't do, we need to return some error code and wpa_supplicant should
> sort it out) I also found only one occurrence in prism54 where the
> parameters are actually not ignored. Is that driver fully replaced by
> p54?
>
> Is there any point in supporting these at all? Does the Libertas 8388
> requires the settings as well instead of just the IE to include?
Libertas driver just uses the WPA1/2 selector stuff internally to figure
out what BSS to associate with; I don't think it's actually needed and
it could certainly be scraped from the IE that the user sets.
For the prism54 driver, I was just translating what the
HOSTAP/PRISM2_IOCTL things did. I never quite understood why there was
a WPA_VERSION selector in IWAUTH, because I thought the IE did that for
us :)
Dan
> I'm inclined to just require userspace to put both the IE and the
> individual settings into the relevant nl80211 messages, but then we
> might just as well piece the IE together from those settings, no?
>
> johannes
On Wed, 2007-03-28 at 10:33 +0100, Mark Powell wrote:
> FWIW we currently use the value of IW_AUTH_WPA_VERSION to generate the
> correct cipher suite selector when forming the set-key request for our
> hard MAC device. We use other IW_AUTH settings too.
Ok so that means we definitely need the individual settings. I thought
so, but wanted to make sure.
> We certainly need the individual settings. It is nice that
> wpa_supplicant generates the IE - it saved me writing the code - but
> that's just being lazy. We still have to modify the IE anyway to add WMM
> stuff.
Do I read that as "I don't care if we get the IE"?
Putting the IE there has the advantage that you can easily play with new
things for cards that use the IE by sticking a few more IEs into the
attribute. But it has the disadvantage that cards behave differently if
you give them contradictory settings. Maybe we need a way to ask a card
which one it wants.
johannes
On Wed, 2007-03-28 at 12:00 -0700, Jouni Malinen wrote:
> Use of WPA/RSN IE vs. individual parameters depends on the driver. For
> example, NDIS drivers generate the IEs internally and need to be
> configured with the key management (WPA-PSK, WPA-Enterprise, WPA2-PSK,
> WPA2-Enterprise, ..) and cipher suites separately. They would not use
> WPA/RSN IE at all. Some drivers use the IE so that kernel code does not
> need to have all the code for generating it. They may (or may not,
> depending on needs) ignore the individual values.
Yes, I know that much.
> > I'm inclined to just require userspace to put both the IE and the
> > individual settings into the relevant nl80211 messages, but then we
> > might just as well piece the IE together from those settings, no?
>
> As long as the information is available for the driver at the time of
> association request, it does not really matter how that information got
> there..
I'd have thought you would rather see the IE included to be able to
experiment with new things easier ;)
I really can't decide which way to use. Piecing together the IE in the
kernel and then just passing it doesn't seem like much overhead, but
doing it in userspace gives us more freedom for experiments...
johannes
Johannes Berg wrote:
> On Wed, 2007-03-28 at 10:33 +0100, Mark Powell wrote:
>
>> We certainly need the individual settings. It is nice that
>> wpa_supplicant generates the IE - it saved me writing the code - but
>> that's just being lazy. We still have to modify the IE anyway to add WMM
>> stuff.
>>
> Do I read that as "I don't care if we get the IE"?
>
We can build it into the driver if we have to :)
> Putting the IE there has the advantage that you can easily play with new
> things for cards that use the IE by sticking a few more IEs into the
> attribute.
I agree. Forming the MLME requests, including the IE, is really the role
of the userland app (the SME in IEEE802.11 speak).
> But it has the disadvantage that cards behave differently if
> you give them contradictory settings. Maybe we need a way to ask a card
> which one it wants.
>
Is that just a case of garbage-in-garbage-out?
Mark
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
On Thu, Mar 29, 2007 at 01:12:19PM +0200, Johannes Berg wrote:
> On Wed, 2007-03-28 at 12:00 -0700, Jouni Malinen wrote:
> > As long as the information is available for the driver at the time of
> > association request, it does not really matter how that information got
> > there..
>
> I'd have thought you would rather see the IE included to be able to
> experiment with new things easier ;)
Looks like there is some misunderstanding here.. What I meant with "the
information" was both the IE and the individual parameters. I do indeed
want to get both of these available to the drivers.
> I really can't decide which way to use. Piecing together the IE in the
> kernel and then just passing it doesn't seem like much overhead, but
> doing it in userspace gives us more freedom for experiments...
I believe both should be provided from user space and kernel has option
of using either one depending on needs.
--
Jouni Malinen PGP id EFC895FA