Making wpa_supplicant work with dhclient on Fedora

[Pavel Polischouk]

Jouni Malinen wrote:
> Why would wpa_supplicant need to run dhclient? 
It doesn't have to. It just needs to run AFTER wpa_supplicant has 
finished establishing the low level link, and get notified when there's 
any change
> I could kind of
> understand this if the IP configuration (DHCP vs. static) would be set
> based on the wireless network (e.g., some networks are using DHCP while
> others use static configuration), but even that case may be handled
> better with something else taking care of running dhclient (or setting
> IP addresses). Anyway, if the interface is always configured to use DHCP
> (which, I would assume, is the most common case), I would just consider
> leaving DHCP client running all the time. This, of course, requires that
> the DHCP clients knows how to figure out when there is need to verify
> that the current configuration is still valid (e.g., ARP ping the
> default gateway) and if needed, request new IP configuration.
>
>   
That's why my first approach was using Dbus (the calls are still there 
in the script, just commented out). It would serve both purposes with a 
single command:
1. If dhclient is not running, dbus will start it.
2. If it is running, it will be notified to gracefully renew the IP lease.

Ideally, the wpa_cli callback script should not call dbus-dhclient 
directly, but rather a new /sbin/ifup style script should be added (say, 
/sbin/ifupdate or /sbin/ifup -renew) that takes care of figuring out if 
the initial static IP/DHCP configuration is needed, or just the renewal.

I think that having wpa_cli monitor the supplicant state is a better 
approach than having dhclient doing ARP ping. It can handle complex 
network conditions more gracefully (e.g. the configuration might be 
conditional on which wireless network the computer is connected to - 
say, static IP for SSID "WORKPLACE" and DHCP for SSID "MyHome") and 
choose the appropriate configuration, while dhclient trying to figure 
out the state of the lower-level network all by itself is not optimal: 
e.g. ARP ping must use some timeout mechanism and is very likely to keep 
the network for too long in disconnected state if the timeout value is 
big, or cause too often and unneeded renewals if the timeout value is small.

Just my 2 cents.


Regards,
Pavel