[PATCH] elektrified wpa_supplicant

[Pedro Ramalhais]

Jouni Malinen wrote:
> On Tue, May 31, 2005 at 08:27:08AM +0100, Pedro Ramalhais wrote:
> 
> 
>>If anyone is interested in testing this, i just finished converting 
>>wpa_supplicant to use libkdb (elektra.sf.net):
>>http://www.uninova.pt/~pmr/files/WPA/hostap-CVS_2005-05-28_elektra2.diff
> 
> 
> I know kdb, but it has nothing to do with elektra, but more so with
> kernel debugging.. ;-) In other words, I'm not familiar with
> libkdb/elektra. Where is it used currently?

The best way to get familiar with the elektra initiative is to read 
about it on the project site (http://elektra.sourceforge.net).
Right now there are patches for init, nsswitch and Xorg.
I just got to know the project last week, and thought it was a good idea 
and thought it would be interesting for wpa_supplicant, so i decided to 
make the initial effort. Some people don't like the idea of a 
system-wide registry (maybe it reminds them of the windows registry and 
makes them skeptical about it). I leave that judgment to you, just read 
the project page and decide for yourself.

> 
> The current patch would need some work on getting rid of ifdef's if it
> is to be merged into my tree. Actually, it might be worthwhile
> implementing this as a separate configuration "provider" as an option to
> the current config.c instead of trying to make both of the
> implementations fit the same file.

At the beginning i thought about separating the implementation 
completely from the original code, but i wanted the configuration 
conversion to be an exact match to the original configuration, so the 
best way was to put the conversion code inside the original 
wpa_config_read() code. I also wanted to use the original parsing code 
(ASCII VS HEX), thus there are some "weird" things like the ssid key 
having the ssid string between parentesis. I made this patch as a 
proof-of-concept, to get the feel of the API and to expose the idea to 
other people since i think it's a good step towards an easier to use 
system and better configuration tools.

> 
> I have some plans on changing the wpa_supplicant configuration interface
> to provide easier way of changing the backend in a similar way to the
> current driver interface. In addition, one part of the planned changes
> would be to add support for storing changes and new data into the
> configuration database (note that a text file is one form of database
> ;-).

libkdb (elektra) also supports different backends. One can write a 
backend lib for a specific config file format so that it is exposed 
through the same libkdb API.
IMHO i think the configuration tool shouldn't be inside the application 
itself. Since it's a daemon, you don't want all that config handling 
code to be residing in memory when it's rarely used. Most people create 
their configs and rarely change them. libkdb API has functions do detect 
when certain keys have been changed, so it's very adequate for what you 
want (maybe tou could make those checks run inside an eloop).

> 
> 
>>Hope this helps creating a configuration editor for 
>>wpa_supplicant/wireless profiles.
> 
> 
> My current priority on this area is in getting the wpa_supplicant
> control interface to support modifying configuration. This would mean
> that the GUI would not need to edit the configuration data file, but to
> use wpa_supplicant to do this. This would then use the selected
> configuration backend (one of which could be Elektra).

As i said above, i would prefer the configuration to be handled outside 
wpa_supplicant and would probably simplify the whole thing. My idea is 
that any application can make use of the data in wireless profiles. 
Think xsupplicant or distribution specific network/wireless config 
tools. The keyword here is interoperability.

> 
> I would hope to get both wpa_gui and wpa_cli using the control interface
> to configure wpa_supplicant. Until this is done, I'm unlikely to have
> much time available on looking at how the configuration database would
> be edited directly without going through wpa_supplicant. Though, of
> course this should not prevent others from working on it ;-).
> 

Same reason here. You're thinking of the wpa_supplicant configuration as 
it's own data, which most of it isn't really. SSID's, keys, passphrases, 
BSSID's, etc... this belongs to OS/network/wireless configuration, so 
the editing shouldn't be handled by the daemon. It could, but i would 
prefer to see OS configuration to be done directly on the system-wide 
"registry" instead of having to interface with wpa_supplicant (which 
would have a specific configuration system). As you can read in 
elektra's project page this is one of the things that keeps users from 
having good system configuration tools, because those tools must have 
code to interface with all the different applications' configuration 
files/systems.

I think you have an idea of why i created this patch and the goal i 
wanted to achieve. I'm not trying to push this to anyone, i just tried 
to see how it would work in a real case scenario(wpa_supplicant being a 
very good test-case) so that i would get a good feel of the API/system. 
Do what you think is best, i trust your judgment capabilities either way 
=:-)

Regards,
-- 
Pedro Ramalhais