netdev
[Top] [All Lists]

Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support

To: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support
From: Jouni Malinen <jkmaline@xxxxxxxxx>
Date: Wed, 2 Jun 2004 06:23:14 -0700
Cc: Netdev <netdev@xxxxxxxxxxx>, hostap@xxxxxxxxx, prism54-devel@xxxxxxxxxxx, Jeff Garzik <jgarzik@xxxxxxxxx>, Jean Tourrilhes <jt@xxxxxxxxxxxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>
In-reply-to: <20040602071449.GJ10723@ruslug.rutgers.edu>
Mail-followup-to: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxxxxxx>, Netdev <netdev@xxxxxxxxxxx>, hostap@xxxxxxxxx, prism54-devel@xxxxxxxxxxx, Jeff Garzik <jgarzik@xxxxxxxxx>, Jean Tourrilhes <jt@xxxxxxxxxxxxxxxxxx>, Linux Kernel <linux-kernel@xxxxxxxxxxxxxxx>
References: <20040602071449.GJ10723@ruslug.rutgers.edu>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6i
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

<Prev in Thread] Current Thread [Next in Thread>