[pkg-wpa-devel] Bug#644251: Bug#644251: wpasupplicant: please make it possible to query for passphrases

[Stefan Lippers-Hollmann]

Hi

On Friday 07 October 2011, Sebastian Harl wrote:
> Hi,
> 
> On Tue, Oct 04, 2011 at 04:47:08PM +0200, Stefan Lippers-Hollmann wrote:
> > On Tuesday 04 October 2011, Sebastian Harl wrote:
> > [...]
> > > 
> > > it would be nice to be able to let wpa-supplicant query for PSKs /
> > > passphrases / whatever when configuring a network in interfaces(5). This
> > > is useful, for example, on shared notebooks or similar.
> > > 
> > > The attached patch allows to specify 'wpa-ask-pass yes' or 'wpa-ask-psk
> > > yes' in interfaces(5). The passphrase / PSK will then be read from stdin
> > > when running 'ifup <iface>'.
> > 
> > How do you imagine this to work, especially considering the auto/ allow
> > hotplug cases in /etc/network/interfaces (ifupdown integration)?
> 
> Hrm, my use-case is using 'ifup' manually once the system is up. Since
> there is no (native) support for auto-detection (afaik) of wireless
> networks, I'd imagine that I'm not the only one doing it that way. (This
> is unless you're using stuff like NM or wicd -- but in those cases my
> approach is not needed anyway. In fact it's my preferred replacement for
> those tools, which allows me to have full control over what is
> happening.)

Did you try a roaming setup with wpasupplicant?

/etc/network/interfaces:

auto lo
iface lo inet loopback

allow-hotplug wlan0
iface wlan0 inet manual
	wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface work inet dhcp
iface home inet dhcp
iface favourite_pub inet dhcp
iface default inet dhcp				# catch all open nets



/etc/wpa_supplicant/wpa_supplicant.conf (or whatever you call it):

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=netdev			# optional, if you want to allow members of netdev to use wpa_gui

network={
	priority=10
	ssid="work_ssid"
	id_str="work"
	proto=WPA2
	pairwise=CCMP
	group=CCMP
	psk="<very secret>"
}

network={
	priority=25
	ssid="home_ssid"
	id_str="home"
	proto=WPA2
	pairwise=CCMP
	group=CCMP
	psk="<very secret>"
}

network={
	priority=5
	ssid="pub_ssid"
	id_str="favourite_pub"
	proto=WPA2
	pairwise=CCMP
	group=CCMP
	psk="<very secret>"
}

network={
        priority=1
        ssid=""
        key_mgmt=NONE
}


This allows automatic roaming and handover without n-m, wicd, etc., 
further info about possible configuration options is under
/usr/share/doc/wpasupplicant/ and /usr/share/doc/wpasupplicant/examples

> Anyway, I'm fully aware that my approach is not suitable for all cases
> but that's why I've added a completely new (and independent of all
> others) option to enable this.
> 
> > > The querying could also be done using zenity/kdialog/whatever -- if the
> > > general approach is fine for you, I'd be happy to modify the patch
> > > accordingly.
> > 
> > The only way I can see this patch working, is if you 
> > strictly don't use /etc/network/interfaces and exclusively invoke
> > ifup/ ifdown from a controlling terminal.
> 
> Well, using /etc/network/interfaces is still fine but the appropriate
> interfaces should not be marked 'auto*'.
> 
> In my case, I've got a few logical interfaces for "known" (wireless)
> networks and depending on where I am, I'm brining up the appropriate
> logical interface using 'ifup'.
> 
> > Looking at your 
> > zenity/kdialog/whatever suggestion it would even have to share the 
> > MIT X11 session cookie to be able to display your X11 based dialog, 
> > which would be totally impossible to invoke from ifupdown.
> 
> Hrm, why would that be impossible? You can still run ifup/ifdown from
> some X-terminal. My zenity/kdialog/whatever suggestion was meant to be
> optional, i.e., I'd check if some X11 display and session cookie would
> be available and fall back to 'read' (and possibly an error message if
> there is no controlling tty) else.

It would be unsuitable for the, imho, most common cases (ignoring 
network-manager setups, but you couldn't use those in combination with 
your proposed patch either) of starting the wlan interface (or roaming)
through /etc/network/interfaces and auto/ allow-hotplug stanzas while 
booting. 

The remaining use case is so specialized:

- must not use auto/ allow-hotplug in /e/n/i
- using a controlling terminal, ideally with X access, in an 
  interactive way is mandatory
- ESSID (usually short) is fixed, but the psk (hopefully long and 
  complex, 63 characters ASCII or 64 hexadecimal digits) needs to be 
  typed every time

that I personally don't consider this to be a viable option for the 
wpasupplicant packages in Debian, because potential users will expect
it to work with auto/ allow-hotplug on boot (similar to booting from an
encrypted rootfs). Especially considering that this functionality could
be provided by relatively simple scripting (add a new network 
definition and switch to it, but don't save it to the config) with 
wpa_cli - if the roaming mode doesn't cover this already.

> > For this particular use case of not storing a psk to disk, wouldn't it 
> > be easier to use wpa_cli or wpa_gui instead, or to make use of a higher
> > level networking interface (e.g. network-manager, wicd, or a simple 
> > custom tools or dæmon making use of wpasupplicant's D-Bus interface)?
> 
> Well, I don't like NM, wicd or other stuff doing certain kinds of magic
> in the background. That's why I like being able to define logical
> interfaces in interfaces(5) and decide on my own, which configuration to
> use. Imho, that's the easiest approach to solving my use case.

I don't like those either, less because of their "magic", but rather 
because of their dependencies (D-Bus) and what I consider massive bugs
(not configurable without X or in and editor, connections might drop
on upgrade (lovely, if you're upgrading over ssh/ wlan, etc. pp.), but
wpasupplicant's roaming mode works fine for me, including very complex
setups and IEEE80211X.

> As mentioned above, I'm fully aware that this does not fit all use-cases
> but imho my approach does not interfere with anything else and others
> might benefit from that as well -- that's why I proposed to include it
> in the package.
[...]

Given how special your proposed operating mode would be and considering
its technical limitations (controlling terminal), I would prefer not 
add this to the generic wpasupplicant package in Debian. Also because
I'm conviced that there would be better approaches to accomplish this
(wpa_cli, either by hand or with rather simple scripting).

(interactive) wpa_cli example, but this could also be scripted:

> add_network
4
> set_network 4 ssid "foo"
OK
> set_network 4 psk "secret"
OK
> enable_network 4
OK
> save_config		# optional, if you want to save this new network
OK

Regards
	Stefan Lippers-Hollmann