[pkg-wpa-devel] Re: wpasupplicant init script

[Reinhard Tartler]

On Mon, Mar 06, 2006 at 09:16:58PM +1000, Kel Modderman wrote:
> Huh? Since when did networking stuff such as this belong in early 
> userpsace? The idea scares me to be honest.

You need it when you want to mount root via nfs across wpa secured
network. Granted, this is not a that common use case, and we don't need
to implement it quickly.

> The idea behind the ifupdown scripts i have begun working on was to 
> allow users who would not like to use an always running daemon but to 
> set static setups in their e/n/i (and build upon these scripts as time 
> and new knowledge allow).

Right. But your scripts allow another usecase: Run wpasupplicant in
roaming mode, but keep the interface up all the time (to the view of
ifupdown). This needs a user provided wpasupplicant, though.

> They are self-contained, and can be *optionally* used instead of an init 
> script (or otherwise) based daemon. It also means that multiple 
> interfaces can spawn their own wpa_supplicant process, a feature which 
> is not supported by any init script so far.

Perhaps we could extend the init script so that the daemon listens to
more than one interface. But I cannot think of any usecase where this
would make sense. If you use the init script, you want some sort of
roaming daemon. Well, perhaps if you run wpasupplicant over both wire
and wireless, and have different networks at your workplace. Hm, I don't
think this is that common, though.

> >I think atheros chipssets are also a quite popular chipset. Which has
> >its own set of problems regarding wpasupplicant. It would be great if
> >wpasupplicant would 'just work' on all chipsets, but this isn't going to
> >happen too soon. Perhaps we can fix issues like #295445 using pci-ids
> >for selected common and tested chipsets.
> > 
> >
> 
> This is a bad idea. If you want wpa_supplicant to support both 
> madwifi-old and -ng, you must go against Jouni's decision to make that a 
> compile time decision. I already asked him directly on hostap + madwifi 
> mailing lists about this very issue. Its not something that should be 
> patched into this package IMHO.

well, we would need to settle on either madwifi or madwifi-ng. Or
provide 2 binary packages for wpasupplicant, compiled for each binary.
But I don't think this is feasible.

What I actually meant is that we could perhaps find some heuristics to
autodetect the variable $IF_WPA_DRIVER for selected chipsets (e.g.
centrino and atheros). These heuristics could use pci ids and can always
be overriden by the user.

> Alternatively, we can co-ordinate the arrival of madwifi-ng into our 
> respective distributions, and adjust wpa_supplicant accordingly 
> (although i have no idea how ubuntu handle madwifi).

ubuntu currently ships madwifi. Madwifi-ng was considered, Adam Conrad
even prepared some test packages for dapper, but it seems that there
were problems. Last time I asked Scott, he told me that dapper will most
likely stay with madwifi. I think that the inclusion of madwifi-ng will
be reconsidered end May or somewhen in June.

> There is currently discussion on the hostap mailing list about adding 
> dbus communication sockets to wpa_supllicant and friends, iirc.

This would be very useful for the NetworkManager developers, who manage
quite everything via dbus (dhclient, etc.).


So, in a nutshell, we can support 3 different modes of operation:

1. Managed mode in /etc/network/interfaces:

example /etc/network interfaces:

iface wlan0 inet dhcp
	wpa-conf managed
	wpa-driver madwifi
	wpa-psk	deadbeefandmuchlongerkey 

wpasupplicant daemon is running as long as the interface is if-up'ed

2. User provided configuration

example /etc/network interfaces:

iface wlan0 inet dhcp
	wpa-conf /home/user/.wpa/wpa_supplicant.conf


wpasupplicant daemon is running as long as the interface is if-up'ed,
the user has to provide a usable wpasupplicant configuration by copying
an example template from /usr/share/doc/wpasupplicant/examples and
editing it.

3. Roaming mode

example /etc/network interfaces:

iface wlan0 inet dhcp

wpasupplicant is started via /etc/init.d/wpasupplicant, and waits for
the interface to come up. This is what the OP poster of this thread
would want to use. Note that this mode won't work on machines affected
by #350963. 

This mode is activated in /etc/default/wpasupplicant. 


Did I miss other modes of operation? 

Gruesse,
	Reinhard