[pkg-wpa-devel] Roaming Daemons

[Reinhard Tartler]

On Sat, Apr 22, 2006 at 03:34:20PM +1000, Kel Modderman wrote:
> Reinhard Tartler wrote:
> >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'
> >  
> 
> Please read: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287223

Err, I don't quite understand. The initscript can surely prepare (i.e.
ifconfig up $IFACE) so that wpasupplicant can start scanning.

> > * 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
> >  
> 
> When a user supplied conffile for a wpa_sup init daemon is used, then 
> wpa-stanzas in /e/n/i should probably be no-act or this system would get 
> very obfuscated. But I am open to suggestion, what do you think?

I think that for this case, /e/n/i shouldn't contain any wpa- stanzas at
all, since they are not needed to configure wpa_supplicant. My 2nd point
requires the user to provide his own wpa_supplicant.conf.

If I understand you correctly, you rather want to do all configuration
in /e/n/i, and make the startscript parse all entries, starting a
wpasupplicant daemon ready for all locations. Interesting concept as
well, but not my intention at this point.

> > * by default, it assumes that the alias in /e/n/i matches the essid
> > * otherwise check a mapping file [optional]
> >  
> 
> Without some worthy workaround/solution to the above mentioned problem 
> (in #287223), mapping may be the only option, right now. Unless of 
> course someone can make wpa_supplicant upstream pass on a shell variable 
> to the action script containing the network block's alias.

What information would you need not provided by 'wpa_cli status'?

> > 
> >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
> >  
> 
> Maybe just ask for a dhcp lease and log the event somewhere.

Sane default. Could/Should work for many cases.

> > * 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?
> >  
> 
> Yes, you cannot bring the interface down or wpa_supplicant will stop 
> scanning. Refer to gentoo's wpa_supplicant ebuild/action-script and 
> baselayout integration (and also discussed on the mailing list by Roy 
> Sharples).

Perhaps we can `ifconfig up` the interface after it was brought down by
ifupdown (if we cannot prevent ifupdown from doing that).

I'll look for gentoo's action-script. Do you have a link to that at
hand?

> >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.
> >  
> 
> I would prefer to move away from using wpa_supplicant as the roaming 
> daemon itself, and use a more generic approach like that used by the 
> project Felix recently mentioned 
> (http://www.tummy.com/Community/software/wifiroamd/). I think that exact 
> project would probably be quite OK if it were modified to map aliases 
> and call ifupdown. This would have the advantage of supporting 
> non-wpa_supplicant supported devices too (ralink, zd1211, acx, rl8180 etc).

I had a closer look at wifiroamd. It works like this:

 * Do 'iwlist $IFACE scan' until a configured location is found. (or use
   the 'default' location)
 * Configure the location
 * checks for hooks to be called
 * monitors the connection by pinging the default gateway

On disconnect (monitor detecting the gateway is down):
 * check for hooks to be called
 * return to 'scan' state.

I'm a bit disappointed because this is another reimplementation of
ifupdown. We could hack this up to integrate it into ifupdown, but is it
really worth the efford? It makes the following assumptions:

 * Only one interface to be managed
 * user provides a new configuration file for each new location
   (specific for wifiroamd, and you have to really how it works for
   setting them
 * no other mechanism is used to control the interface.
 * the interface understands 'standards' iwtools commands. Since the
   behavior differs on different drivers, the user can put his own
   initialisation hooks in a reset.d hookdir

It resembles a bit wifi-radar (a pygtk application), imo.

We could of course reuse some of this concepts, but if you look at that
more closely, we would basically need the loop which does the actual
scanning and the monitor, which periodically checks if the interface was
still active. And my thoughts was about using wpa_supplicant's action
scripts for this task. The hooks and configuration of the interface
would be delegated to ifupdown.

Gruesse,
	Reinhard