wpa_cli event handling (revisited)

Kel Modderman kelrin at tpg.com.au
Sat Jun 3 21:27:31 EDT 2006


Roy Marples wrote:
> On Tuesday 30 May 2006 10:18, Reinhard Tartler wrote:
>   
>>> Just out of curiosity, can ifupdown handle this?
>>>       
>> The problem is that ifupdown records the 'state' of an interface:
>>     
>>> ifup eth0 (or some other trigger)
>>>       
>> You mean e.g. a cardbus card has been inserted and udev triggers a ifup
>> eth0.
>>     

This is true for Ubuntu, iirc. Debian's ifupdown requires the 
"allow-hotplug" class to be used when this behaviour is desired (IMHO, 
this behaviour should be configurable, whether or not it is enabled by 
default or not).

In this case (wired interface), I'd prefer the trigger to be originating 
from an ifplugd daemon (re)acting to an "cable insertion" event on the 
iface. ifplugd may have been started by an init script.

Wireless iface's are best started automatically to make use of the 
following scheme.


>>     
>>> netplugd is launched
>>> netplugd triggers ifup eth0 as cable is in
>>>       
>> ifup will fail with 'interface already configured'
>>     

ifplugd ifup's the iface. This iface is configured (in the 
/etc/network/interfaces file, and uses the ifupdown.sh hook[1]) to spawn 
a wpa_supplicant process with the appropriate wpa_supplicant.conf file, 
as well as spawning a wpa_cli daemon that uses a wpa_action[2,3] script 
designed to control the ifupdown state of the iface.

This iface, the "master" iface, uses the manual inet method, no other 
network configuration is done at this stage. The current state of the 
iface in /etc/network/ifstate is "iface=iface". (this could possibly be 
improved by introducing a "silent" class for ifupdown, whereby the iface 
can be up'd without its state being recorded).

>>     
>>> wpa_supplicant is launched with -Dwired on eth0
>>> wpa_cli triggers final ifup eth0
>>>       
>> and here again.
>>     

wpa_action is given the CONNECTED event signal, and WPA_ID_STR of the 
current network is exported to it.

wpa_action executes 'ifup --force iface=WPA_ID_STR', configuring the 
iface with the network settings specific for that location (each 
WPA_ID_STR requires an /etc/network/interfaces block that substitutes 
"iface" for WPA_ID_STR, and contains the network setting appropriate for 
the location), and changing the ifstate to "iface=WPA_ID_STR". Only when 
the state is initially of the form "iface=iface" will the --force option 
be used by wpa_action. This is necessary to ignore the unconfigured 
state of the "master" iface, and use the nice ifupdown features to apply 
the network settings.

On the consequent DISCONNECTED signal, wpa_action will execute 'ifdown 
iface=WPA_ID_STR', reversing the previously applied settings. The iface 
will now be absent from the ifstate file. Alternatively, ifplugd can 
reverse the network settings with 'ifdown iface', and the mapped state 
recorded in the ifstate file (iface=WPA_ID_STR) ensures that the correct 
network profile is used.

If a CONNECTED event is received again, wpa_action will execute 'ifup 
iface=WPA_ID_STR', and so the cycle continues until wpa_cli is 
terminated, or the networking services are stopped.


>>     
>>> Just curios as I had a forum request for Gentoo to handle that and it
>>> took some time to get it working as all enterance points from daemons are
>>> net.eth0 start.
>>>       
>> The problem here is to define what 'configuring an interface' actually
>> means, because ifupdown has its own POV about this.
>>     
>
> I would like to know how is problem - if it is indeed perceived to be a 
> problem is solved then :)
>   


Thanks, Kel.

[1] 
http://svn.debian.org/wsvn/pkg-wpa/branches/wpasupplicant-0.5/debian/ifupdown.sh?op=file&rev=0&sc=0
[2] 
http://svn.debian.org/wsvn/pkg-wpa/branches/wpasupplicant-0.5/debian/wpa_action.sh?op=file&rev=0&sc=0
[3] http://users.tpg.com.au/sigm/misc/pkg-wpa/wpa_action.html



More information about the HostAP mailing list