[pkg-wpa-devel] What's wrong with the new configuration scheme, IMO

Felix Homann fexpop at onlinehome.de
Wed Apr 19 21:48:33 UTC 2006 

Hi,

here's a write-up on what I think is wrong with the new
config scheme. Please, read without prejudice, think about it - and
only then stone me ;-)

Kind regards,

Felix

Content
=======

1. Conceptual flaws
  1.1 Abuse of /etc/network/interfaces (/e/n/i)
  1.2 ifup before connect
  1.3 New config scheme makes debugging more complicated
  1.4 Note on similarity to wireless-tools
2. Mode specific flaws
  2.1 Mode 1 / "Managed mode"
  2.2 Mode 2 without action script
     2.2.1 Unclear mixing of concepts
     2.2.2 Unclear configuration priorities
  2.3 Mode 2 with action script
     2.3.1 Improper for roaming
3. Conclusion
Links and notes


1. Conceptual flaws
===================

1.1 Abuse of /etc/network/interfaces (/e/n/i)
---------------------------------------------

As I see it /e/n/i is about network interface configuration. The wpa-* stanzas 
are not used to configure an interface but a daemon process.

This is taken to the extreme in the dhclient setup suggested in
README.Debian: /e/n/i is only used to configure the wpa_supplicant
process, while the network interface configuration is completely
deligated to the action script.

1.2 ifup before connect
-----------------------

In the wired world you're usually able to tell very clearly if the cable is 
plugged in. Only then does it make sense to ifup the respective 
interface.

I like to think that connecting to/associating with an AP is somehow
the wireless equivalent to plugging the cable in [1]. Within this picture,
the new scheme tries to let ifup plug the "cable" in. I don't think
that's something ifup should do.

Moreover, ifup should not even try to configure the interface unless it is 
connected to an AP. Otherwise ensuring correct (or intended) behaviour
of scripts in /e/n/if-up.d is very difficult. [2]


1.3 New config scheme makes debugging more complicated
------------------------------------------------------

In the new config scheme the wpa_supplicant process is started and
stopped by ifup/ifdown. Errors can occur in two different phases of the
ifup/ifdown process - the wpa_supplicant part and the actual network
interface configuration part. Since you can't easily start them
seperately - especially in a mode 1 setup - debugging gets more
difficult.

(I personally had to fight with this when I tried to set up a mode 1
configuration [3]; you might even enjoy Kel's suggestion to
emulate the script for debugging [4]).


1.4 Note on similarity to wireless-tools
----------------------------------------

The package maintainers tend to think that the new config scheme is
just like the integration of wireless-tools in ifupdown. It is not,
since iwconfig does neither configure and start a background process nor does 
it rely on one. iwconfig really configures an interface.



2. Mode specific flaws
=======================


2.1. Mode 1 / "Managed mode"
---------------------------- 

Apart from points already mentioned in section 1 there's not much wrong with 
mode 1, but a few minor issues remain.

(i)  Having one stanza to specify the ssid from wireless-tools and one from 
     wpa-supplicant is not the best solution.

(ii) wpa-stanzas used in /e/n/i should be consistent with 
     wpa_supplicant.conf. E.g. using quotes in wpa_supplicant.conf but not 
     in /e/n/i is confusing, "psk=" in  wpa_supplicant.conf should translate 
     to "wpa-psk" in /e/n/i not "wpa-passphrase".


2.2 Mode 2 without action script
--------------------------------


2.2.1 Unclear mixing of concepts
................................

Mode 2 mixes up concepts. The new configuration scheme tries to pull
configuration of wpa_supplicant into /e/n/i and then the wpa-conf
stanza pushes it out again. 

If you really want to have the capability of connecting to different APs 
within the new config scheme, put this feature entirely into /e/n/i, by e.g. 
introducing a "wpa-config-block" stanza, or suggest using logical
interfaces in mode 1 (does that work?).


2.2.2 Unclear configuration priorities
......................................

As it is now you can use the wpa-conf stanza in combination with any other 
wpa-*-stanza. It is not clear how this is handled, at least it's not 
documented. Do stanzas in /e/n/i override settings in the .conf file,
are they ignored, etc.? 

I think mixing wpa-conf with other wpa-*-stanzas (apart from 
maybe wpa-action related stanzas) should lead to an error. [9] 

(BTW, what effect would a wireless-essid statement in /e/n/i have on a
wpa-ssid statement?)


2.3 Mode 2 with action script
-----------------------------

In addition to the handing out of interface configuration to an action script
there are even more issues.

2.3.1 Improper for roaming
..........................

Although the documentation claims that "With action scripts, you can develop 
your own advanced roaming configuration." I don't think you can.

IMO, a proper roaming solution should fulfill these minmal demands:

(1) Not try to configure the network if it is not even connected to an
    AP.
(2) Nicely work together with the rest of network configuration. In
    particular, it should properly make use of what's in
    /etc/network/if-*.d.

The only proposed "roaming solution" so far is using the
wpacli-action-dhclient script from the examples directory. It will
probably work fine the first time you ifup the interface if it can
connect to an AP. On every subsequent 'connect' it will only run
dhclient, the scripts in /e/n/if-*.d will be ignored.  

*The only way to fix it is to essentially reimplement ifupdown in the
action script!* 

Moreover, due to issue 1.2 above, the scripts in /e/n/if-up.d
will be run on ifup even if there is no configured AP available or the
radio is off. Scripts that check for an available IP (like zeroconf)
will misbehave (actually they do as they are written, but they are not
intended to be used on an interface that is not even "plugged in").

As long as there is no way of preventing the scripts from /e/n/if-up.d
from being executed on ifup, the use of wpacli-action-dhclient will
lead to unintended behaviour when it can't connect to an AP (unless
/e/n/if-up.d is more or less empty). 

Please, even note that the package maintainers of wpasupplicant failed to
show that even rather simple roaming configurations can be developed
with an action script + mode 2. On the contrary - they 
admitted that they don't have or don't care about such solutions.[5-8] 

3. Conclusion
=============

Most of all, I'd suggest rethinking mode 2. As it is now, it should
not be suggested to be used together with the wpacli-action-dhclient
script, as the README does. Using it together with an "iface wlan inet
dhcp" line should be OK, but still seems conceptually wrong to me
(for 1.1).

On a further note, I would recommend reading the README and
README.Debian from the guessnet package, they contain some valuable
thinking. (Note that the information on waproamd is outdated, but in
most places you can just think of wpa_supplicant when waproamd is
mentioned.)
 
 
Links and notes
=========================
 
[1] Yes, I know it also does encryption, key handling, etc.
[2] see the zeroconf issue:
 http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000195.html
[3]
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000221.html
[4]
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000240.html
[5] 
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000219.html
[6] 
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000195.html
[7] 
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000209.html
[8] 
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2006-April/000210.html
[9] Actually, I think mode 2 should not be used at all.

More information about the Pkg-wpa-devel mailing list