Braindump on wpa_supplicant

[Dan Williams <dcbw redhat com>]

Hi,

So sitting in the airport at 10:30 at night last week I took a look at 
wpa_supplicant again.  Again I've flip-flopped, I'm thinking that making a 
"slave" mode may be the best choice, but there are some utter stupidities in 
wpa_supplicant that make it a difficult.

First, wpa_supplicant has a "wpa_supplicant" structure that encapsulates the 
information for one network interface.  Internally, the program keeps track of 
all interfaces using a linked list of wpa_supplicant structures.  Each structure 
has a pointer to common configuration information, but there can also be one 
config file per interface, each with different options.  In this case, the 
config structure points to that config file.

Here's where it gets fun.  To control wpa_supplicant, it exposes a control 
socket for _each interface_.  There is no control socket until you have told 
wpa_supplicant to use that interface.

Second, wpa_supplicant expects a static list of interfaces when it starts up.  
Even if the interfaces are not actually present on the system yet, if you ever 
want to use, say, ath0 in the future, you have to start wpa_supplicant and tell  
it about ath0.  It will sit around waiting for ath0.  But this essentially 
means, wpa_supplicant cannot deal with random interfaces inserted at any time, 
because the interface needs to be preconfigured somewhere.

So there are two issues with "slave" mode.  First, you cannot start up 
wpa_supplicant without telling it about at least one network interface, which we 
don't know at startup time.  Second, there is no "daemon" control socket, 
because control sockets are created per-interface.

So the solution I was working on is essentially this:

1) Create a new "wpa_controller" structure that, when initialized, creates a 
control socket that exists from startup->shutdown
2) Use this control socket to tell wpa_supplicant about new interfaces when 
NetworkManager detects them
3) When wpa_supplicant creates the control socket for the new interface, use 
that to tell wpa_supplicant what, exactly, to do with that interface
4) Use the daemon control socket to tell wpa_supplicant when a network
interface goes away

The wpa_supplicant file is so byzantine that its almost comical.  We simply 
cannot expect users to configure all the options it exposes.  I'm still not sure 
how to deal with scanning, since wpa_supplicant has hooks into each driver to 
retrieve each driver's idea of custom scan events that expose the actual WPA 
data.  We could rely on wpa_supplicant to do scanning for us (or, perhaps, only 
when we ask it to scan) and then read the scan data from wpa_supplicant on a 
per-interface basis.  That's a lot of work though.

In any case, wpa_supplicant needs some major changes architecturally to deal 
with network interfaces not being present when it starts up.  The other solution 
would be to start 1 instance of wpa_supplicant per-interface (even wired 
interfaces may need 802.1x authentication), and ignore the resulting memory 
bloat.  I'm not sure I like this option, but it would be easier to get upstream 
and wouldn't require as much work to wpa_supplicant.

Dan