Re: WPA_Supplicant slave mode patch

[Dan Williams <dcbw redhat com>]

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).

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.

Looking good,
Dan