[PATCH] elektrified wpa_supplicant
Wed Jun 1 18:25:03 PDT 2005
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):
> 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
> 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
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
More information about the Hostap