[RFC, (buggy) PATCH] Importing systemwide wireless configuration from wpa_supplicant.conf

[Kevin Kofler <kevin kofler chello at>]

Hi,

[Resending my message from 2008-09-28 20:29 UTC after the usual "subscribe, 
disable mail delivery" routine. <RANT>It's extremely annoying to have to 
subscribe to every single of the hundreds of mailing lists one wants to send 
even a single patch to. But it's even MORE annoying when one gets an 
autoreply that the message is "held for moderation", but nobody actually 
checks the moderation queue. If you're going to reject all messages from 
unsubscribed users, please at least say so outright.</RANT>]

This is an idea I had yesterday. It starts from a problem statement:
* Being able to use system-wide wireless keys is beneficial for several 
reasons:
- able to connect before / without a GUI login
- no need to unlock the GNOME keyring all the time
- and other reasons as outlined at: 
http://bugzilla.gnome.org/show_bug.cgi?id=331529
http://live.gnome.org/NetworkManagerToDo
and other places.
* However, at least the Fedora ifcfg infrastructure only supports basic (and 
highly insecure) WEP, no WPA nor 802.1X.

Faced with this, I thought of something: in fact, we already have a 
well-recognized format to specify WPA or 802.1X settings in: 
the /etc/wpa_supplicant/wpa_supplicant.conf config file. That file is 
normally ignored or overridden when wpa_supplicant is started through NM, but 
I can't think of any reason why we can't import its settings into NM and 
reuse them that way. The benefits from this approach:
- it's an existing format, not a new NM-specific format which would have to be 
designed
- well-known format, documented in tutorials all over the Internet
- distro-independent, so we don't have to reinvent the wheel for each distro
- can represent WPA and 802.1X (and WEP and unencrypted WiFi too)
- settings can be tested rapidly without going through NM (just start 
wpa_supplicant directly with the config file)
- NM uses wpa_supplicant internally, so the format maps well to NM's view of 
things

So, as per the above, I got the idea for a nm-system-settings plugin using 
wpa_supplicant.conf. And in fact, I tried implementing it myself and ended up 
with this (buggy) patch (against the NM revision in current Fedora, revision 
4022):
http://www.tigen.org/kevin.kofler/pcprogs/NetworkManager-0.7.0-wpa.patch
Unfortunately, the patch does not work at all for me: sometimes I get 
the "System myssid" connection, but can't do anything useful with it (in 
particular, can't connect to it, nor does it connect automatically), 
sometimes not even that (i.e. I don't get the connection at all), and 
unfortunately my skills at debugging NM stop there. :-(

I also have this quick&dirty specfile to build the plugin as a separate Fedora 
package for testing:
http://www.tigen.org/kevin.kofler/pcprogs/NetworkManager-wpa_supplicant.spec
Unfortunately, the file /etc/NetworkManager/nm-system-settings.conf which 
specifies the plugins to load is not marked %config(noreplace) in the Fedora 
NM package, so editing that file is a bit of a hack (and the package which my 
specfile builds doesn't try to do that automatically, it has to be done by 
hand - alternatively, my patch can be applied to the regular NM package and 
the config file just edited there, but that's not so nice for 
testing/debugging).

There are also other things in the patch which could use improvement:
- The inotify stuff is adapted from the fedora-ifcfg plugin in a quick&dirty 
way. I'm sure we could simplify it a lot here, as we only have one file to 
monitor, not an entire directory.
- 802.1X support is currently limited to LEAP. It is possible to parse all the 
advanced 802.1X stuff too, just not implemented yet because I think getting 
the rest (unencrypted, WEP, WPA and LEAP) to work first is more important. 
(And to be honest, also because WPA and LEAP are all I personally need at the 
moment. ;-) ) There's a FIXME for this, it's easy to spot because it's a 
function of its own which just returns NULL. ;-)
- In some places, wpa_supplicant.conf supports lists of possible settings, but 
NM only supports one single setting at a time, so I'm throwing the excess ones 
out for lack of a better solution. As far as I can tell, improvements to the 
NM core would be needed to fix this problem. There are FIXME comments next to 
the affected places.

        Kevin Kofler