So WPA is now a priority for prism54 development. Here's where we're at.
Long ago in January Jouni had added some wpa supplicant support into
prism54. It's not until today when I started looking into
wpa_supplicant.
I'm glad wpa_supplicant exists :). Interacting with it *is* our missing
link to getting full WPA support (great job Jouni). In wpa_supplicant
cvs I see a base code for driver_prism54.c (empty routines, just providing skeleton).
Well I'll be diving in it now and see where I can get. If anyone else is
interested in helping with WPA support for prism54, working with
wpa_supplicant is the way to go.
I'm curious though -- wpa_supplicant is pretty much userspace. This was
done with good intentions from what I read but before we get dirty
with wpa_supplicant I'm wondering if we should just integrate a lot of
wpa_supplicant into kernel space (specifically wireless tools).
Regardless, as Jouni points out, there is still a framework for WPA that needs
to be written for all linux wireless drivers, whether it's to assist
wpa_supplicant framework or to integrate wpa_supplicant into kernel space.
What's the plan?
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
On Wed, Jun 02, 2004 at 03:14:49AM -0400, Luis R. Rodriguez wrote:
> I'm glad wpa_supplicant exists :). Interacting with it *is* our missing
> link to getting full WPA support (great job Jouni). In wpa_supplicant
> cvs I see a base code for driver_prism54.c (empty routines, just providing skeleton).
> Well I'll be diving in it now and see where I can get. If anyone else is
> interested in helping with WPA support for prism54, working with
> wpa_supplicant is the way to go.
I have a bit more code for this in my work directory somewhere (setting
the WPA IE and a new ioctl for this for the driver). I did not submit
these yet since the extended MLME mode was not working and the changes
were not yet really working properly. I can try to find these patches
somewhere.. Anyway, I would first like to see the extended MLME mode
working with any (even plaintext) AP and then somehow add the WPA IE to
the AssocReq. After that, it should be only TKIP/CCMP key configuration
and that's about it..
> I'm curious though -- wpa_supplicant is pretty much userspace. This was
> done with good intentions from what I read but before we get dirty
> with wpa_supplicant I'm wondering if we should just integrate a lot of
> wpa_supplicant into kernel space (specifically wireless tools).
Why? Which functionality would you like to move into kernel? Not that
I'm against moving some parts, but I would certainly like to hear good
reasons whenever moving something to kernel space if it can be done (or
in this case, has already been done) in user space..
> Regardless, as Jouni points out, there is still a framework for WPA that needs
> to be written for all linux wireless drivers, whether it's to assist
> wpa_supplicant framework or to integrate wpa_supplicant into kernel space.
The first thing I would like to see is an addition to Linux wireless
extensions for WPA/WPA2 so that we can get rid of the private ioctls in
the drivers. Even though these can often be similar, it would be nice to
just write one driver interface code in wpa_supplicant and have it
working with all Linu drivers.. I hope to find some time to write a
proposal for this.
--
Jouni Malinen PGP id EFC895FA
On Wed, Jun 02, 2004 at 06:23:14AM -0700, Jouni Malinen wrote:
> On Wed, Jun 02, 2004 at 03:14:49AM -0400, Luis R. Rodriguez wrote:
>
> > I'm glad wpa_supplicant exists :). Interacting with it *is* our missing
> > link to getting full WPA support (great job Jouni). In wpa_supplicant
> > cvs I see a base code for driver_prism54.c (empty routines, just providing skeleton).
> > Well I'll be diving in it now and see where I can get. If anyone else is
> > interested in helping with WPA support for prism54, working with
> > wpa_supplicant is the way to go.
>
> I have a bit more code for this in my work directory somewhere (setting
> the WPA IE and a new ioctl for this for the driver). I did not submit
> these yet since the extended MLME mode was not working and the changes
> were not yet really working properly. I can try to find these patches
> somewhere.. Anyway, I would first like to see the extended MLME mode
> working with any (even plaintext) AP and then somehow add the WPA IE to
> the AssocReq. After that, it should be only TKIP/CCMP key configuration
> and that's about it..
If you find the patches that'd be great :). I'll see what I can do about
fixing up extended MLME. I'll keep you posted.
> > I'm curious though -- wpa_supplicant is pretty much userspace. This was
> > done with good intentions from what I read but before we get dirty
> > with wpa_supplicant I'm wondering if we should just integrate a lot of
> > wpa_supplicant into kernel space (specifically wireless tools).
>
> Why? Which functionality would you like to move into kernel? Not that
> I'm against moving some parts, but I would certainly like to hear good
> reasons whenever moving something to kernel space if it can be done (or
> in this case, has already been done) in user space..
I have yet to review most of the wpa_supplicant code so I cannot say for
sure yet what I think should go into the kernel. I e-mailed most lists
mainly to get comments from others who have poked at wpa_supplicant
and/or are looking into adding WPA client support into their drivers.
I just wanted to make sure we were heading in the right direction since
I only see 2 drivers that are currently using wpa_supplicant.
> > Regardless, as Jouni points out, there is still a framework for WPA that needs
> > to be written for all linux wireless drivers, whether it's to assist
> > wpa_supplicant framework or to integrate wpa_supplicant into kernel space.
>
> The first thing I would like to see is an addition to Linux wireless
> extensions for WPA/WPA2 so that we can get rid of the private ioctls in
> the drivers. Even though these can often be similar, it would be nice to
> just write one driver interface code in wpa_supplicant and have it
> working with all Linu drivers.. I hope to find some time to write a
> proposal for this.
I agree :). Jean? *poke*
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
On Wednesday 02 June 2004 12:14 am, Luis R. Rodriguez wrote:
> So WPA is now a priority for prism54 development. Here's where we're at.
> Long ago in January Jouni had added some wpa supplicant support into
> prism54. It's not until today when I started looking into
> wpa_supplicant.
>
> I'm glad wpa_supplicant exists :). Interacting with it *is* our missing
> link to getting full WPA support (great job Jouni). In wpa_supplicant
> cvs I see a base code for driver_prism54.c (empty routines, just providing
> skeleton). Well I'll be diving in it now and see where I can get. If anyone
> else is interested in helping with WPA support for prism54, working with
> wpa_supplicant is the way to go.
>
> I'm curious though -- wpa_supplicant is pretty much userspace. This was
> done with good intentions from what I read but before we get dirty
> with wpa_supplicant I'm wondering if we should just integrate a lot of
> wpa_supplicant into kernel space (specifically wireless tools).
> Regardless, as Jouni points out, there is still a framework for WPA that
> needs to be written for all linux wireless drivers, whether it's to assist
> wpa_supplicant framework or to integrate wpa_supplicant into kernel space.
>
> What's the plan?
I think wpa_supplicant takes the right approach (i.e. putting the majority of
the code in user space). The supplicant is not performance intensive and
there's little justification for it going in the kernel on other grounds
(like security). I've had madwifi working with wpa_supplicant for quite a
while and have also done a rough port of wpa_supplicant to the bsd world too
so it's design is proven (and in general I think it's excellent work).
I'd second Jouni's comments about moving the wireless extensions support
forward. Aside from WPA there are a few private mechanisms required for
multi-mode devices that should be handled through a standard API.
Sam
On Wed, Jun 02, 2004 at 11:55:42AM -0400, Luis R. Rodriguez wrote:
> If you find the patches that'd be great :). I'll see what I can do about
> fixing up extended MLME. I'll keep you posted.
I now know where the wpa_supplicant part is and once I find the matching
patch for Prism54 driver, I'll send them both to you.
> I have yet to review most of the wpa_supplicant code so I cannot say for
> sure yet what I think should go into the kernel. I e-mailed most lists
> mainly to get comments from others who have poked at wpa_supplicant
> and/or are looking into adding WPA client support into their drivers.
> I just wanted to make sure we were heading in the right direction since
> I only see 2 drivers that are currently using wpa_supplicant.
You may have seen only two drivers, but actually I'm already aware of at
least seven drivers that work with wpa_supplicant.. All of these are not
yet available publicly, though.
I believe that the current design for wpa_supplicant is quite alright
for most cases. I would like to give some more thought for the roaming
part (i.e., consider giving more control for the driver), but this
should be doable in a backward compatible way without breaking support
with existing code.
--
Jouni Malinen PGP id EFC895FA
Pre-Scriptum: Please excuse me for cross posting and/or if this mail is
not relevant for the recipient mailing list/people.
Hi Jouni (and other interest wireless driver developers)!
As you may know (or not), the ipw2100 driver is somewhat based on hostap
code. We use some code from hostap in the ipw2100 driver, and use the
hostap driver externally as a way to provide WEP.
I'm currently working on turning hostap_crypt* into ieee80211_crypt* in
such a way that could be used in a generic way by all drivers that need
host based WEP (and TKIP/CCMP). I basically renamed the hostap_crypt* to
ieee80211_crypt* and search&replaced hostap with ieee80211. Also made
hostap_crypt.c into a module (instead of having to rely on hostap.o).
I have WEP working and a Makefile that can be used in the kernel or
externally. I took a look at the TKIP and CCMP source files and it is
somewhat tied up to ioctls and headers (just took a quick look correct
me if i'm wrong) from hostap. This makes it somewhat difficult to turn
them into code that compiles without hostap code.
Besides this, the ipw2100 code also has an attempt at a somewhat generic
ieee80211 interface for drivers. ieee80211_rx.c is mostly based on
hostap_hw.c code (which looks like is now in CVS as hostap_80211_rx.c )
and there's also ieee80211_tx.c which i think was created from scratch
by James Ketrenos (ipw2100 main developer @intel).
My question is: would it be interesting to try and merge code from
hostap, ipw2100 and possibly other drivers to try to create generic code
for 80211 and 80211_crypt? How much interest is there on the part of the
developers (hostap, prism54, atmel, etc...). I'm asking this because
AFAICS, the hostap driver always had an history of more focus on new
features, functionality, bug fixes, than "standard" APIs, etc... and i
completely understand that and thank god it has been like this because
the final result was a really nice driver.
Would you accept patches at least for now to make hostap_crypt* into
ieee80211_crypt*?
Sorry, i have so many questions and ideas, that i cannot express myself
very well =:-).
This is getting lengthy, so, hope you got the idea at least of some of
my questions/ideas/worries, etc....
Thank you!
PS: Comments, ideas, proposals, etc are welcome for discussion.(What is
the best way to discuss this matter? There's a large number of
developers involved. Maybe netdev?)
On Thu, 2004-06-03 at 02:40, Jouni Malinen wrote:
> On Wed, Jun 02, 2004 at 11:55:42AM -0400, Luis R. Rodriguez wrote:
>
> > If you find the patches that'd be great :). I'll see what I can do about
> > fixing up extended MLME. I'll keep you posted.
>
> I now know where the wpa_supplicant part is and once I find the matching
> patch for Prism54 driver, I'll send them both to you.
>
> > I have yet to review most of the wpa_supplicant code so I cannot say for
> > sure yet what I think should go into the kernel. I e-mailed most lists
> > mainly to get comments from others who have poked at wpa_supplicant
> > and/or are looking into adding WPA client support into their drivers.
> > I just wanted to make sure we were heading in the right direction since
> > I only see 2 drivers that are currently using wpa_supplicant.
>
> You may have seen only two drivers, but actually I'm already aware of at
> least seven drivers that work with wpa_supplicant.. All of these are not
> yet available publicly, though.
>
> I believe that the current design for wpa_supplicant is quite alright
> for most cases. I would like to give some more thought for the roaming
> part (i.e., consider giving more control for the driver), but this
> should be doable in a backward compatible way without breaking support
> with existing code.
--
Pedro Ramalhais <[email protected]>
On Thu, Jun 03, 2004 at 03:38:05AM +0100, Pedro Ramalhais wrote:
> As you may know (or not), the ipw2100 driver is somewhat based on hostap
> code. We use some code from hostap in the ipw2100 driver, and use the
> hostap driver externally as a way to provide WEP.
> I'm currently working on turning hostap_crypt* into ieee80211_crypt* in
> such a way that could be used in a generic way by all drivers that need
> host based WEP (and TKIP/CCMP). I basically renamed the hostap_crypt* to
> ieee80211_crypt* and search&replaced hostap with ieee80211. Also made
> hostap_crypt.c into a module (instead of having to rely on hostap.o).
I do not understand what kind of changes you think are required.
Renaming the functions/structures is not really changing anything and
hostap_crypt.o used to be a separate module (and it should still be
possible to compile it as such by defining HOSTAP_CRYPT_MODULE when
compiling the Host AP code).
It sounds like your changes are just making it more difficult to
maintain generic code because of making it require more work to merge
changes back. With the changes to use crypto API, there's already couple
of different versions of the crypto code for Host AP. I would rather not
bring in more versions. The improvements should go to the wireless-2.6
tree.
As far as I can tell, the version that I submitted couple of days ago
for wireless-2.6 (and potentially linus-2.5) trees, should be usable as
is from other drivers. Yes, hostap module will include some extra
functionality that is not needed, but it does not make it any more
difficult to use the encryption part which should be fully hardware
independent. This can be easily (again) extracted, if it looks like this
code will be used from multiple drivers.
> I have WEP working and a Makefile that can be used in the kernel or
> externally. I took a look at the TKIP and CCMP source files and it is
> somewhat tied up to ioctls and headers (just took a quick look correct
> me if i'm wrong) from hostap. This makes it somewhat difficult to turn
> them into code that compiles without hostap code.
Tied to ioctls?? There is no ioctl processing in the Host AP crypto
code. The header files are mainly for defining the IEEE 802.11 header.
In addition, Host AP code can already be used in the kernel and
externally..
> Besides this, the ipw2100 code also has an attempt at a somewhat generic
> ieee80211 interface for drivers. ieee80211_rx.c is mostly based on
> hostap_hw.c code (which looks like is now in CVS as hostap_80211_rx.c )
> and there's also ieee80211_tx.c which i think was created from scratch
> by James Ketrenos (ipw2100 main developer @intel).
This sounds similar to what the current Host AP driver uses
hostap_80211_{rx,tx}.c.
> My question is: would it be interesting to try and merge code from
> hostap, ipw2100 and possibly other drivers to try to create generic code
> for 80211 and 80211_crypt?
Yes and this is what has been discussed on netdev and (admittedly,
slowly so far) started with wireless-2.6.
> developers (hostap, prism54, atmel, etc...). I'm asking this because
> AFAICS, the hostap driver always had an history of more focus on new
> features, functionality, bug fixes, than "standard" APIs, etc... and i
> completely understand that and thank god it has been like this because
> the final result was a really nice driver.
I believe that one needs to first experiment with the features/design
before being able to design a standard API. There has already been quite
many versions of Linux wireless extensions and I would rather first see
what would be a common design that could work with most wireless cards
and then design an API for this. For many functions, we are starting to
have all the needed information to actually to this successfully.
> Would you accept patches at least for now to make hostap_crypt* into
> ieee80211_crypt*?
Sure, if there is something that really improves the current situation
in some way. I don't think that just renaming the functions would be
very useful at that point. Of course it can be done, but I would prefer
to see a bit more design on the other parts of the IEEE 802.11 support
and its place in the Linux net stack.
> PS: Comments, ideas, proposals, etc are welcome for discussion.(What is
> the best way to discuss this matter? There's a large number of
> developers involved. Maybe netdev?)
netdev
--
Jouni Malinen PGP id EFC895FA
Jouni Malinen wrote:
> The first thing I would like to see is an addition to Linux wireless
> extensions for WPA/WPA2 so that we can get rid of the private ioctls in
> the drivers. Even though these can often be similar, it would be nice to
> just write one driver interface code in wpa_supplicant and have it
> working with all Linu drivers.. I hope to find some time to write a
> proposal for this.
One of the things that is nice about wireless-2.6 is that is affords the
opportunity to totally rethink the wireless extensions.
Although a lot of people would howl, since HostAP is essentially new
code from the mainline kernel perspective, a new userland API (and new
or updated tools) could come along with it.
I have mentioned in the past (no offense Jean!) that I do not like the
overly-generic wireless handler structure. It is less type-safe than is
generally preferred in Linux, IMO.
A low-level wireless driver should not implement ioctls, it should
implement callbacks in some sort of 'struct wireless_operations' as is
done in other kernel subsystems.
ioctl details should be hidden from low-level drivers as much as
possible, through type-safe interfaces. Strive to make both the
wireless driver API and the wireless userland API easy to change and
evolve over time.
Jeff
To all,
I'm sorry to break into this thread, but I was just curious as to what will
eventually happen to wpa_supplicant. Based upon Mr. Malinen's words, as well as what
a few others in this thread have been saying, will WPA and 802.1x eventually become
generalized driver frameworks in the kernel (like MII), using the current Crypto API
and crypto drivers?
I'm just asking from an enduser perspective here, because eventually I will be
purchasing an 802.11g Prism54 device and would like to have an idea of the relative
ease of configuring 802.1x and WPA in the future.
Thanks,
Brad
=====
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
On Wed, Jun 02, 2004 at 11:55:42AM -0400, Luis R. Rodriguez wrote:
> On Wed, Jun 02, 2004 at 06:23:14AM -0700, Jouni Malinen wrote:
> >
> > The first thing I would like to see is an addition to Linux wireless
> > extensions for WPA/WPA2 so that we can get rid of the private ioctls in
> > the drivers. Even though these can often be similar, it would be nice to
> > just write one driver interface code in wpa_supplicant and have it
> > working with all Linu drivers.. I hope to find some time to write a
> > proposal for this.
>
> I agree :). Jean? *poke*
>
> Luis
The initial plan was for me to get more familiar with WPA, but
this keep slipping (partly due to family matters). HP did follow my
suggestions and use IPsec internally, which also explain why I'm in no
hurry. There was some stuff I wanted to "improve" in the API design,
but I guess that if I can't deliver a patch, I'd better shut up and
try to avoid being a bottleneck.
At this point, I think that Jouni is our best expert on the
subject, and the fact that many driver has reused his API means that
his API is sensible and flexible enough.
So, the plan would be to take Jouni's API as is (or with minor
modifications) and stuff that in wireless.h. I don't believe that the
tools themselves need to be modified, because wpa_supplicant is the
sole user of those ioctls.
If you are all happy with that, then I'll just do it.
Have fun...
Jean
On Thu, Jun 03, 2004 at 12:06:35AM -0400, Jeff Garzik wrote:
>
> One of the things that is nice about wireless-2.6 is that is affords the
> opportunity to totally rethink the wireless extensions.
>
> Although a lot of people would howl, since HostAP is essentially new
> code from the mainline kernel perspective, a new userland API (and new
> or updated tools) could come along with it.
>
> I have mentioned in the past (no offense Jean!) that I do not like the
> overly-generic wireless handler structure. It is less type-safe than is
> generally preferred in Linux, IMO.
>
> A low-level wireless driver should not implement ioctls, it should
> implement callbacks in some sort of 'struct wireless_operations' as is
> done in other kernel subsystems.
>
> ioctl details should be hidden from low-level drivers as much as
> possible, through type-safe interfaces. Strive to make both the
> wireless driver API and the wireless userland API easy to change and
> evolve over time.
>
> Jeff
Jeff, I'm amazed that you are so obsessed with this. Yes,
Wireless Extension could be improved in millions ways, but at least
it's working, whereas there are so many other areas where we have
nothing at all. If you talk with most people developping wireless
drivers, this doesn't even make their list. But I guess every one of
us need to have his hot topic ;-)
I believe most people are concerned about :
o WPA support (and security API in general)
o SNAP encapsulation/decapsualtion in kernel
o handling 802.11 frames natively in kernel
o handling 802.11 management in kernel (association/deassociation, ...)
Personally, those are my priorities :
o getting more wireless drivers in the kernel
o RtNetlink API for Wireless Extensions
I also explained you how you could wrap around Wireless
Extension trivially to introduce a new driver API without breaking the
many user space tools, so that you can implement your proposal with
maximum backward compatibility. Just because there is one aspect of
the API you don't like, we don't need to throw away the good parts.
Have fun...
Jean
On Thu, Jun 03, 2004 at 09:52:33AM -0700, Jean Tourrilhes wrote:
> So, the plan would be to take Jouni's API as is (or with minor
> modifications) and stuff that in wireless.h. I don't believe that the
> tools themselves need to be modified, because wpa_supplicant is the
> sole user of those ioctls.
> If you are all happy with that, then I'll just do it.
I'm mostly happy with this, but this should also include something from
the private ioctls hostapd uses for AP functionality. In addition, I
would consider changing couple of text based elements (e.g., WPA IE as
hex string) to binary in order to remove extra parsing code and make the
data contents smaller. I'm having quite a bit of problems with scan
results getting too large for the current limit of 4 kB.. Admittedly,
this is in a test lab environment, but still, it is annoying and
requires workarounds like driver side filtering of the scan results.
I could try to make a list of all private ioctls currently used in
wpa_supplicant and hostapd, including some comments on what I would
consider changing at this point (mostly, changing text binary for couple
of cases and removing some fields that are not really going to be used).
Main categories for new functionality would be:
- key configuration (multiple algorithms, individual/unicast keys,
packet number set/get),
- WPA (or actually, generic) information element (get from scan results,
set for (Re)AssocReq/Beacon/ProbeResp)
- MLME requests (deauth/disassoc; maybe associate, too; I'm currently
using SIOCSIWAP for this; scan request with SSID (and maybe also
channel list) for active scanning
- authentication mode/encryption algorithm parameters (Host AP driver
does not current use this, but this is the way WPA drivers are used in
Windows NDIS and some Linux driver authors prefered this option and
wpa_supplicant supports it as an optional mechanism)
- some encryption related events/parameters (reporting Michael MIC
errors, TKIP countermeasures, configuration of "drop unencrypted" and
"privacy invoked").
Once we get some kind of testing version done, I will add a new driver
interface code for wpa_supplicant for the generic Linux wireless
extensions case and modify Host AP driver to use this. I hope that other
drivers would also start to use the new API at some point, although
wpa_supplicant is likely to maintain the backwards compatible interface
code for some time.
--
Jouni Malinen PGP id EFC895FA
On Thu, Jun 03, 2004 at 07:33:03PM -0700, Jouni Malinen wrote:
> On Thu, Jun 03, 2004 at 09:52:33AM -0700, Jean Tourrilhes wrote:
>
> > So, the plan would be to take Jouni's API as is (or with minor
> > modifications) and stuff that in wireless.h. I don't believe that the
> > tools themselves need to be modified, because wpa_supplicant is the
> > sole user of those ioctls.
> > If you are all happy with that, then I'll just do it.
>
> I'm mostly happy with this, but this should also include something from
> the private ioctls hostapd uses for AP functionality.
Obviously we need the full functionality, not just some part
of it.
> In addition, I would consider changing couple of text based elements
> (e.g., WPA IE as hex string) to binary in order to remove extra
> parsing code and make the data contents smaller.
The downside of that is that things need to be predefined. As
we are doing a "WPA API" and not a "generic link layer security API",
that's OK.
The other thing you may want to think about is miving all
string/arrays at the end of the definition so that we can grow them
easily if needed, and so that the first part can be fixed.
> I'm having quite a bit of problems with scan
> results getting too large for the current limit of 4 kB.. Admittedly,
> this is in a test lab environment, but still, it is annoying and
> requires workarounds like driver side filtering of the scan results.
That's easy to fix. I did the same with "iwpriv" definitions a
couple of weeks ago. Basically, you return -E2BIG to user space until
userspace give you a big enough buffer.
I'll try to fix that.
> I could try to make a list of all private ioctls currently used in
> wpa_supplicant and hostapd, including some comments on what I would
> consider changing at this point (mostly, changing text binary for couple
> of cases and removing some fields that are not really going to be used).
You currently have your plate pretty full. I'll try to help,
but my first son was born one month ago and things are not as smooth
as planned.
> Jouni Malinen
Jean