[pkg-wpa-devel] Bug#360387: new mode 3 proposal

[Reinhard Tartler]

On Sun, Apr 02, 2006 at 09:07:58PM +0200, Joachim Breitner wrote:
> The big advantage of this is that
>  a) you can have different ifupdown settings for different locations. I
> have quite complex stuff configured there (e.g. different VPNs to be put
> up, modifying /etc/ld.preload for tsocks, etc). 

Why isn't this possible in action scripts as well?

>  b) cat /etc/network/run/ifstate says what devices are _really_ up, not
> what wifi devices are sitting and waiting for access points.

Do you really rely on this? Does this really get updated when you loose
connection to your location in the old method?

>  c) /e/n/interfaces configs refer to _networks_, not hardware, which
> makes a log of sense IMHO

Well, this is a quite philosophical argumentation. You cannot really
argue that 'lo' more a network than a device, but you configure it in
/e/n/i as well. 

The mapping thingy in ifupdown can be used to describe networks. But I
think this is rather a hack than a well designed feature.

> With this wpa-action command (which seems like yet an other point during
> interface upbringing where to run commands), I can no longer
> differentiate the different physical networks
> _in_ /etc/network/interfaces, unless of course I did not understand it
> correctly.

You can of course differentiate between physical networks. It is a plain
shellscript, so you can call any command you want, including whereami or
'wpa_cli status', which I would suggest to learn your current ssid.

> A possible further way, which might neatly integrate into ifupdown, just
> crosses my mind:
> Why not use wpasupplicant as a mapping script, from ifupdowns POV? For
> every different WLAN I would want to connect to, I have a separate
> virtual device in /e/n/i, kind of like with guessnet. ifupdown calls
> some script as a mapping script, which will fire up wpa_supplicant and
> wait, until wpa_supplicant could connect to one of these defined
> networks, and then return to ifupdown the virtual interface name of the
> associated network. 

Interesting idea, I never thought about this before. But unfortunately,
I don't get the point about this setup. In that mapping script, you
would have to start wpasupplicant as daemon, and then wait for it to
call the action script to call back (via some state file or other
facility) and tell you the location wpasupplicant has connected right
now. This is returned then to ifupdown (what should happen at this point
if authentication fails or no AP is available?)

Then ifupdown maps the current location and configures the interface
described for this mapping. the ifupdown scripts needs to detect that
the interface has already been set up and only need to configure it.

Is this really worth the efford? To me, it seems that there is a lot of
efford just to keep this ifupdown mapping feature alive. Whats the
problem with configuring the interface in the action script? For more
complicated setups, there is wherami. I'm currently working on decent
integration with whereami currently.

> This would have the advantage that is just an extension of mode 1, i.e.
> if you want to "upgrade" from mode1 to mode3, you just add the mapping
> line and add interfaces as you wish.

Instead of keeping the mapping feature of ifupdown alive, I'd rather
vote for working on a more generic action script, and provide the user
facilities to configure his location more easily than what we currently
have today.

Given that there is work on providing dbus support for wpasupplicant, it
seems to me that the future lies in writing a roaming daemon, which
interacts with wpasupplicant in a nice way to learn the current location
and configure the interface to the location's and user's needs.
Currently, I know only of network-manager doing something like this, but
I don't think that there can't be an alternative to that.

Gruesse,
	Reinhard