[pkg-wpa-devel] Re: Roaming Daemons

[Kel Modderman]

Reinhard Tartler wrote:
> 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.
>   

An ssid may have spaces or other weird characters in it, this would 
require mapping or some sort or alias to be able to fit in with what 
/e/n/i requires: a single string for iface.

>   
>>> * 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.
>   

One or the other; my point being that ifupdown's wpasupplicant hook 
would have to be no-op when wpa_supplicant is used the way you like, so 
we need to add a check for that in wpasupplicant.ifupdown.

>   
>>> * 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'?
>   

A single string to map to an iface in /e/n/i.

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

I do not think ifupdown can be prevented from doing that.

Gentoo's networking baselayout has some functions that quietly 
deconfigure a device without bringing it down and afaik ifupdown does 
not have this (depending on differences in installed components, eg. 
dhclient from dhcp-client or dhcp3-client).

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

You can find it in their files digest of their ebuild mirrors or so, 
don't have the link handy. But the script is simply what you already 
have in mind, more or less.

>>> 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).
>>     
>
>
> 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.
>   

I only skimmed over the wifiroamd code, there were bits i liked and bits 
that were ugly, and I offered only a quick first impression.

wpa_supplicant does the scanning very nicely indeed; it is proven. As 
more and more wifi interfaces become wext compliant, this choice becomes 
a non-issue.

Thanks, Kel.