[PATCH] elektrified wpa_supplicant

[Pedro Ramalhais]

Jouni Malinen wrote:
> On Thu, Jun 02, 2005 at 02:25:03AM +0100, Pedro Ramalhais wrote:
> 
> 
>>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.
> 
> 
> wpa_supplicant "configuration" may need to change even when the user is
> not doing this explicitly. For example, EAP-FAST updates keying material
> automatically and this data needs to be stored somewhere. Consequently,
> wpa_supplicant needs to be able to store data no matter how the
> configuration database is maintained and using the same mechanism for
> storing both the network configuration and automatically provisioned
> keying material sounds like a good way to do this.
> 

How do you currently do it? Does this info need to be saved between each 
session? Anyway you can save it to the profile using 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.
> 
> 
> If multiple programs are going to use the same configuration data, there
> would need to be some kind of mechanism for making sure that the
> configuration profile is compatible. In other words, this sounds like
> something that is requiring more coordination (i.e., more work) and I
> don't know whether the end result would be worth this extra effort.
> 

At some point this should be done (in fact it should've been done a long 
time ago). I guess the option here would be to create a library for 
editing the wireless configuration (maybe it wouldn't be that difficult 
since elektra is able to output in XML format so the structure/data 
could be checked with a schema). On the other hand i don't see it as a 
big problem currently. If there's a key we don't recognize, just ignore 
it (much like wpa_supplicant does with it's conf file. If you're talking 
about compatibility of the data itself, what usually is done is that 
someone defines the "standard" and other prople follow it, otherwise 
they should increase the number on the config_version key of the 
profiles tree.

> 
>>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).
> 
> 
> Are you saying that there should be some kind of system wide
> configuration tool that would take care of all configuration, i.e., it
> would need to know details of all programs running on the system. For
> example, in case of wpa_supplicant, it would need to know how to get
> scan results and fill in defaults for a new network block.
> 

Take redhat-config-network, YAST, webmin, etc... webmin knows many apps' 
configuration files(many different config formats, which is actually 
where elektra gains if most apps used it) and how they're configured. 
They could get the scanning info from libiw or wpa_supplicant (via the 
CTRL_INTERFACE).

> I don't see all Linux distributions standardizing on a single
> configuration tool any time soon and as such, it sounds like quite a bit
> less work to maintain one GUI tool for wpa_supplicant which includes
> configuration management that can be used with all existing
> distributions..
> 

Well, they really should, but that's not the point. The point is that 
they can use the same profile format as the other distributions, and 
wpa_supplicant too. Even if you create wpa_supplicant GUI, it won't take 
long until some distribution tries to add that capability to their own 
tools, and then there we go again: each one writing the specific config 
file format parser, each distro puting the config file where it feels 
like, and any app that simply needs access to that info has to write the 
parser too and find where the hell did the distros decided to put the 
config file today.

-- 
Pedro Ramalhais