Discontinuing kcmwifi for wpa_supplicant, what about knetworkmanager?

[Stefan Winter]

Hello k-c-d,

Quoting Dirk Mueller:
> Sure, I would also consider it to be a bugfix. and if you have a patch to
> make kwifimanager work for non-root users as well, then that would also be 
> great ;)

Well. That brings up something I had in my mind for far too long already. I am 
seriously thinking of discontinuing the kcmwifi module for KDE4. The reasons 
for that are many:

1) in its current state, its usability sucks (and I can say that without 
stepping on anyone's feet, because I'm the main "UI designer" for the thing)
2) it supports only WEP, and adding more to it is a big conceptual change
3) there is at least one other, better solution out there

1) is something I could address; in fact, I began with that some time ago, and 
even got the blessing of some usability folks
2) is something I'd like to explain a little further: dynamic WEP, and 
WPA/WPA2 Enterprise need to constantly have a connection on layer 2 to 
negotiate their dynamic keys, (re-)authenticate the user etc. So it would 
require a change from a stand-alone kcm towards a daemon, possibly a suid 
root one - with all the security precautions that are connected to suid root.
So, my best option to address 2) and add WPAx support would be that I take an 
existing supplicant software (that's the 802.1X terminology for the 
layer-2-talking software) and create a wrapper/GUI around that. It would 
still be a hassle to do so, because it's not only about remote-controling 
another app by writing config files for it, but also constant state 
monitoring to keep the link at layer 2 happy and inform the user how things 
are at the moment.
The second-best option would be to keep control over everything that's not 
dynWEP or WPAx related, and pass the user on to some other app when he 
selects dynamic encryption. This would be a major confusion for the user I 
guess.
3) wpa_supplicant. It's that easy. This software is the supplicant, as the 
name suggests. It also contains a GUI, and even a Qt based one: wpa_gui. 
Fairly easy to use, and despite its name it can not only handle WPA networks 
but also WEP or clear-text networks, IOW: everything. And when it comes to 
WPAx Enterprise authentication, it really shines. There are a lot of 
authentication protocols out there to use for 802.1X authentication, and 
wpa_supplicant supports a wide variety. I seriously doubt that any other 
supplicant (except maybe xsupplicant, but that one doesn't have a real GUI) 
can currently do a better job. For those of you still reading and wondering 
why I started this mail quoting Dirk: you can even use it as non-root. The 
trick being that the wpa_supplicant daemon runs as root, but has a control 
interface, and it is configurable which unix group shall have the right to 
issue control commands. So, put "users" into the control-allowed group and 
you're done: all your users have administrative access to the WLAN NIC.

[ OT: Whether or not it is advisable to give users control over the networks 
they enter is a different question - there are certainly lots of reasons why 
ifconfig has ever since been root-only. Especially with wireless networks 
whose identity can be rather effectively faked this may not be the wisest 
thing to do. But that's a completely different question. ]

Now, after all this said, let's take a look at the KNetworkManager proposal 
from kde-devel a few hours ago.
This is an utility that can only handle WEP currently, but at least has a 
daemon running in the background. That's a nice start at least. The web site 
claims that WPA support is going to be there "soon". If it happens, fine. But 
especially with the whole lot of authentication protocols for WPAx in the 
wild, supporting only a decent subset would be a PITA if they do it 
themselves, and it would sure be error-prone in the beginning. If, on the 
other hand, they use wpa_supplicant or xsupplicant (unlikely, the state 
monitoring part has no real interface to the outside world; I tried it once) 
in the backend, my next question would be: why duplicate things others have 
done already? Or worse, wrap around something that the other guys understand 
a lot better than you (since these other guys developed it themselves)? So, 
unless the KNetworkManager guys can give some *concrete* hints about their 
planned WPA support, I would definitely favorise to take wpa_supplicant, and 
turn it from a Qt3 to KDE4 GUI. I would even volunteer for that - along with 
some minor wishes I have for wpa_supplicant (it still has a few config 
options that are not yet available from the GUI, namely CA root selection and 
exact CN matching for the presented server certificate for the TLS-based 
authentication algorithms, and some things are missing, e.g. no DHCP/IP 
settings after successful auth).

I am aware that KNetworkManager does also other things, i.e. wired LAN. That's 
a plus for it. But doing WLAN layer 2 *right* is damn difficult, so it's IMHO 
a far better idea to trust this to people that can dedicate their efforts 
towards it and not do a one-size-fits-all approach.

Now, coming to the end, I should say that none of this has to do with 
KWiFiManager, the monitoring app. I will still maintain and further develop 
that.

BTW, I'm planning to be at aKademy in Dublin - maybe some other people 
interested in wireless LAN are there as well, so we can discuss stuff? Or the 
Solid guys, that would be nice.

Oh, and here some links:

wpa_supplicant: http://hostap.epitest.fi/wpa_supplicant/wpa_gui.html
wpa_gui: http://hostap.epitest.fi/wpa_supplicant/wpa_gui.html
xsupplicant: http://open1x.sourceforge.net/

Greetings,

Stefan Winter

-- 
The K Desktop Environment
- Stefan Winter -
Areas of Activity:
kdenetwork/wifi (KWiFiManager)
kde-i18n/de (German translation)