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

[Reinhard Tartler]

On Fri, Mar 03, 2006 at 11:20:34AM -0500, Jason Lunz wrote:
> > This is a more advanced usage of wpasupplicant. It requires in every
> > case manual editing of an wpasupplicant configuration file,
> 
> well, sort of. The default wpasupplicant configuration file will
> associate with any open AP, so that part's fine. What requires manual
> configuration is ifplugd.
> 
> Any time I want to add a WEP/WPA-protected AP, I only have to add a
> single stanza to wpasupplicant.conf. Everything else is already set up,
> assuming the network has DHCP.

This doesn't work cleanly on every available WLAN Chipset. I'm very
unhappy that this used to be the default mode in wpasupplicant in the
past, because my driver (madwifi-old) has problems with this mode of
operation.

> > and I can imagine that his doesn't work with all available drivers.
> 
> True, but I intend to continue submitting patches to any wireless
> drivers I use to make them work this way. I've done so for bcm43xx
> already, though that driver has more basic problems with roaming that
> make this rather useless atm.
> 
> The actual change is very simple; it's only necessary that the driver
> reports carrier while associated and vice-versa.

And it is necessary that the driver supports background scanning, which
isn't supported by madwifi.

> > We we currently plan is that it should be possible to configure the most
> > common setups (wpa-pks, peap, etc) in /etc/network/interfaces. As you
> > pointed out, this wont work for your setup. For your setup, you indeed
> > need some kind of init script to run wpa_supplicant all the time.
> 
> I think this is going in the wrong direction. I would say the common use
> case for wireless is a roaming laptop, and a static configuration isn't
> very well-suited to that.

I agree, but I think that having the local admin editing
/etc/wpa_supplicant.conf to add the credential which are needed to
connect to your network is static configuration as well, which I don't
like too much.

> I think some inter-package coordination is needed in debian so that
> a straightforward roaming-wireless-laptop is either the default, or is
> easily set up by installing a few packages by flipping a setting
> somewhere. We're not very far from that, really, though it took me a
> while to figure that out.

Right. I've seen that use-case working in ubuntu/dapper using
NetworkManager and ipw2200 drivers. Worked like a charm (modulo of wpa
not supported in that version of Network Manager).

Having said this, I want to repeat my observations about this problem:

There are users who have an wireless router at home and have configured
them to make wpa-psk only. Perhaps they use different interface aliases
in /etc/network/interfaces, so configuration can be completly in
/e/n/i without issues. This is what I want to become the default mode of
operation, because it is way easier to configure. Think about
configuration tools like gnome-system-admin editing /e/n/i as well.

There are also users who use wpasupplicant as replacement for wparoamd.
This is quite hard to support, because we need to require the user to
provide a usable wpasupplicant.conf. This used to be the default mode in
the past. Your mail (and another request I got in private) convinced me
that we need to support this mode of operation as well.

The latter mode gets especially quite problematic in the case of
mkinitramfs, which brings the interface up in the early userspace. This
was the main reason why we wanted to remove the init script altogether.
In order to solve this problem nicely, we would need to make sure that
wpasupplicant binary gets into the initramfs along with a suitable
config. You can now imagine that this gets way easier when we just
consider the first mode of operation I described above.

But in fact, also the latter mode would be doable, if debian's initramfs
would already mount /var/{run,lock} as tmpfs, just like ubuntu already
does. In this case, we could fire it up in the early userspace and
forget about it. The initramfs needs to be regenerated every time the
configuration changes, though.

Now the question: How do we proceed from here? I can think that our
ifupdown scripts should also support an always running wpasupplicant
daemon, which was started either by early userspace or an ordinary
initscript. Therefore I will see if I find some time tomorrow to
reenable the initscript and extend (and of course test) Kels work on the
hooks.  If this works somehow, I intend to get this package uploaded to
experimental, in order to get some broader testing. If everyone is happy
again, then lets get this work back to the stable branch of
wpasupplicant.

Regarding our 'stable' branch (i.e. svn trunk): I think I will prepare
an upload updating to 0.4.8 and see if we can satisfy the request of the
debian utopia team.

How does this sound?

> There's now a GPL bcm43xx driver in linux for the broadcom chipsets. The
> state of the in-kernel intel centrino ipw2xxx is improving. So it seems
> likely that in etch, it should be possible for a majority of laptops to
> simply work like this out of the box. I don't think it should be an
> "advanced configuration".

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.

I also think that the usecase you presented us is a local user alone on
his laptop who moves from one wireless net to another. I don't think
that he should have to edit /etc/wpa_supplicant.conf everytime he moves
to a new network, requiring root priviledges. To satisfy this usecase, I
think some real interface managing service like NetworkManager is the
right way. Unfortunately, I've seen frontends for Gnome and KDE only up
to now. But since all communication is via DBUS, it should be rather
easy to implement a simple CLI application which allows the user to edit
his network settings without the requirement to be root.

I understand that this is not possible right now. Therefore I agree that
we should keep the solution we had in past releases of wpasupplicant.
Nevertheless, the local admin should have to enable it manually. This
was already the case in past releases of the package, IIRC.

Gruesse,
	Reinhard