[pkg-wpa-devel] Bug#360387: new mode 3 proposal Was: Bug#360387: wpasupplicant: please support the "old" daemon mode as an configuration option

Joachim Breitner nomeata at debian.org
Sun Apr 2 19:07:58 UTC 2006


Hi,

Am Sonntag, den 02.04.2006, 15:19 +0200 schrieb Joerg Platte:
> Am Sonntag, 2. April 2006 07:15 schrieben Sie:
> > Personaly, I had no objection to the init script being included, but not
> > active. However, it had severe limitations, and as new programs emerge,
> > that can handle your wifi profiles (eg. network-manager) using far
> > superior methods than an init daemon + ifplugd (or whatever), it is
> > important that we move on with some lower level integration of
> > wpa_supplicant with out networking scripts, imho.
> 
> I'm using this "mapping" stuff, because it's very easy to write my own options 
> to /etc/network/interfaces and parse them with a script 
> in /etc/network/if-up.d. And this options and scripts can be used either by 
> Wifi or Ethernet interfaces. This makes it very convenient. I don't know 
> network-manager in detail, but if the same functionality is possible, I may 
> switch to it. 

I have to second this wishlist bug. Just two weeks ago, I was active on
the pkg-wpa-devel mailinglist, until it was agreed that mode 3 should
still be possible, so I am a bit dumbfounded to see it removed now.

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). 
 b) cat /etc/network/run/ifstate says what devices are _really_ up, not
what wifi devices are sitting and waiting for access points.
 c) /e/n/interfaces configs refer to _networks_, not hardware, which
makes a log of sense IMHO

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.

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. A possible /e/n/i might then look like this:

auto wifi0

mapping wifi0
  script /usr/lib/wpa-ifupdown-mapping

iface wifi0-home dhcp
  wpa-driver madwifi
  wpa-ssid homezone
  wpa-key-mgmt WPA-PSK
  wpa-psk 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
  up echo I'm home| mail -s Hi honey at my.family

iface wifi0-work manual
  wpa-driver madwifi
  wpa-ssid bigcorp
  wpa-key-mgmt WPA-EAP
  wpa-identity just_me
  openvpn company-central backdoor-to-home 

iface wifi0-public dhcp
  wpa-driver madwifi
  wpa-ssid ANY


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.

I'm looking forward your comments.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: joachimbreitner at amessage.de | http://people.debian.org/~nomeata





More information about the Pkg-wpa-devel mailing list