Re: WPA_Supplicant slave mode patch

[Tim Warberg <twarberg gmail com>]

On 6/15/05, Dan Williams <dcbw redhat com> wrote:
> On Sat, 2005-06-11 at 15:16 +0200, Tim Warberg wrote:
> > Hi,
> >
> > Had some spare time (didn't feel like reading) and "finished" up
> > wpa_supplicant  changes. Added a slave mode where config can be
> > changed dynamically through socket.
> >
> > I've added a "network" command to socket interface. Takes 1 argument,
> > a string of network options (same options as in config file) separated
> > by ; and ended by ;;. Example:
> > "network ssid="something";proto=WPA;key_mgmt=WPA-PSK;pairwise=TKIP;group=TKIP;psk="verysecretpassphrase";;"
> >
> > Also added a way to chance ap_scan(See config file) behavior: "set AP_MODE # "
> > where # is mode number.
> >
> > If we don't want any other wireless scanning, ap_scan must be 0. In
> > this mode wpa_supplicant won't do any WPA association and must be done
> > by NM. See association function in each of the wpa_supplicant drivers.
> >
> > Slave mode is activated by wpa_supplicant option -S
> >
> > Only testet with WPA-PSK connection at my parents. I'll test WPA
> > EAP-TLS when I'm back home.
> >
> > Todo:
> > non hardcoded ctrl socket file path
> 
> Great!  Sorry I didn't reply sooner, been bogged down in a bunch of
> other stuff.  So besides the hardcoded ctrl socket, what's left to do?
> Has the wpa_supplicant maintainer commented on this patch at all?  Also,
> how do we pass RSN preauth data from NetworkManager->wpa_supplicant, is
> that covered at this time? (its binary data up to 200-some bytes long).

How much left depends on your answer to this:
Currently Slave mode can operate in 2 ways. Default mode is to wait
until association is done by something outside wpa_supplicant (look at
association function in  wpa_supplicant drivers source). Hence NM have
to do the wpa association which is driver depended. Until 802.11 stack
is merged into kernel anyway.
Other one, wpa_supplicant does scanning but because it only have one
network config it won't do anything unless network is in range.
Whether that's a problem you tell me ;). Hmmm guess we need a way to
make wpa_supplicant sleep and resume or simply execute and terminate
wpa_supplicant when needed and not.

Not yet sure how much work is needed to make use of association
function in wpa_supplicant but as far as i know only WPAIE has to be
parsed and that's 26 bytes long.

> I recently looked over the config file for wpa_supplicant again and got
> greatly depressed; its got a ton of options that a user should never,
> ever have to touch.  I'm hoping we can do a much better job from the
> user-experience perspective on the front end, keeping wpa_supplicant on
> the backend doing the work but exposing as little of its gory config
> details to the user.

What kind of WPA access point is set up for (WPA or RSN (WPA2) and
WPA-PSK or WPA-RADIUS) and which encryption algorithm (TKIP or AES)
can all be read from WPAIE. This should simplify things allot.
WPA-RADIUS i think is primarily used in enterprise or by technical
skilled persons and they should be able to set correct options. Please
correct me if I'm wrong!

-- 
Tim Warberg
Email: twarberg at gmail.com