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

[Kel Modderman]

Felix Homann wrote:
> 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.
>   

The previous reply dealt with this section. I believe your synopsis is 
flawed, not the method by which ifupdown spawns a wpa_supplicant daemon 
in the new scheme.

> 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]
>   

This is something the planned wifiroamd plans to address. Please join 
the effort.
>
> 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 agree, there is already a bug open with a patch to wpa_supplicant to 
allow logging, maybe you or I could revive that thread on the hostap 
mailing list?

> (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]).
>   

You "enjoyed" it?

>
> 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.
>
>   

I'm not sure exactly what your point is here.

>
> 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.
>   

It is required, providing a means of accepting either one would be nice, 
but technically wrong.
> (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".
>   

This is something I battled with for a long time when I was "debating" 
with the ubuntu crowd. The decision to make no option require quotes 
caused a lot of time and effort to be spent on my part. I would love to 
hear other opinions on this topic.

>
> 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?).
>   

wifiroamd.

>
> 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.? 
>   

Well, the stanza provided by /e/n/i are appended to the ctrl_interface , 
which has already read in the network blocks from the .conf file. 
Therefore, the conf file will always override.
> I think mixing wpa-conf with other wpa-*-stanzas (apart from 
> maybe wpa-action related stanzas) should lead to an error. [9] 
>   

No, I disagree. There is no harm done here. Additionally, I can use the 
conf file, but still create a new network via /e/n/i, and the new 
network block can be used. There is no conflict or problem here that I 
can see.
> (BTW, what effect would a wireless-essid statement in /e/n/i have on a
> wpa-ssid statement?)
>   

Don't know, some buggy drivers have required this in the past for proper 
association etc.

>
> 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.
>   

Yes it can, although it would require an advanced and highly customised 
action script.
> 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] 
>   

I am not trying to offer any sort of full roaming system, the removal of 
the init script create a void. Without the removal of it, I would never 
have known to setup 3 different packages to achieve connection to my 
access point, because it was not documented.

> 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).
>   

A difference in expectations and opinions, I respect yours. But must the 
same point be brought up time and time again?

I guess it is obvious that we should scrap reference to the action 
scripts from the documentation, at least not suggest them as a preferred 
mode. I would like to keep the code that supports them around however, 
because I personally find it useful and interesting.

Dbus interface in the new wpa_supplicant coupled with a dbus aware 
dhcp-client would be a nice solution too ; )

Thanks, Kel.