[pkg-wpa-devel] What's wrong with the new configuration scheme, IMO

[Reinhard Tartler]

On Fri, Apr 21, 2006 at 10:51:09AM +0200, Alexej Davidov wrote:
> > And why bother if there are plans already in place to make a
> > "wifiroamd"?
> I agree with most of Felix' points. I also agree with Kel, that many of
> the mentioned issues won't be issues any more, as soon as there is some
> "wifiroamd". The problem, I think, was bad timing. Changing the
> configuration scheme with wifiroamd in mind which does exist yet. Thus
> breaking the working config of many people, who now have to wait for
> wifiroamd to get back a setup that has worked well for them. 

Well, we don't prevent using the package as it has been used before, we
now even provide the init script in the examples/ directory again.

But we don't want to have it installed by default, because we really
don't think that this belongs in the wpasupplicant package.

I have made some thoughts about a package which works like this:

 * Start wpasupplicant as system service (daemon).
 * Make the daemon use an action script.
 * the action script checks what location we connected to (look at the
   essid), and does this:
   * determine which network alias in /e/n/i this location is associated
   * call ifupdown like this: 'ifup $IFACE=$LOCATION'
 * On disconnection, the action script ifdowns $IFACE

This package makes the following assumptions:

 * Only one interface is to be managed
 * The user provides a usable wpa_supplicant.conf
 * all locations are configured in /e/n/i
 * by default, it assumes that the alias in /e/n/i matches the essid
 * otherwise check a mapping file [optional]
 
Problems which I still have to think about:

 * What happens if we connect to a yet unconfigured location?
   * Ideally, we would need to inform the user and ask him to provide
     configuration to /e/n/i
   * at least, it should log this event via syslog
 * What if there have been no locations configured yet? (shall
   wpasupplicant run anyway, allowing managing of wpa_supplicant.conf 
   via wpa_cli/wpa_gui, or should it doesn't start the daemon at all?)
 * ifdown will bring the link down. Does this confuse wpasupplicant too
   much?

I think this follows the guessnet/ifplugd configuration scheme, but I
haven't looked too much into guessnet yet. I intend to work on such a
package this weekend. But I hope you can understand that I/(we?) don't
want this functionality in the 'wpasupplicant' package.

> > >> Dbus interface in the new wpa_supplicant coupled with a dbus aware
> > >> dhcp-client would be a nice solution too ; )
> > > Maybe, but why not first look what can be done with tools that
> > > already exist? 
> > It already exists, see the changelog of the upstream development
> > (0.5) series of wpa_supplicant for more info. I am very tempted to
> > begin packaging this beast.
> 
> Do we really need a dependency to dbus? There is hotplug/udev, where
> you can do all kind of fancy stuff with hardware on detection. Then
> there is ifplugd which takes care of network interfaces going down or
> up. I think this is the most flexible and powerful solution without the
> introduction of additional requirements. dbus, as I understand it, is
> mainly used by Desktops and GUI applications. I don't think it's a good
> idea for such a basic thing as networking to depend on such a
> high-level thing as dbus.

Why do you think it was limited to desktop and gui applications?
Currently, Gnome, Network-Manager and other Desktop infrastructure uses
dbus, right, but there are already bindings for dhcp-client and hal for
dbus. 

dbus promises to provide a decent interface for all kind of
applications. E.g. wpasupplicant can send a signal to dhcp-client, that
the interface is now ready to be configured and it should start asking
for a lease. At the same time, there might be (or not) a monitoring
application (be it gui or not), which receives these events as well,
without wpa_supplicant nor dhcp-client needing to care about. 

Perhaps another argument can convince you: Currently, ifplugd has to run
with root priviledges. For monitoring these actions, you need
priviledges as well. With dbus, you don't necessarily need these
priviledges anymore. It depends on the configuration of the system dbus,
which the local administrator can configure.

Gruesse,
	Reinhard