Making wpa_supplicant work with dhclient on Fedora
j at w1.fi
Wed Jun 11 12:09:27 EDT 2008
On Wed, Jun 11, 2008 at 11:18:58AM -0400, Pavel Polischouk wrote:
> I think that having wpa_cli monitor the supplicant state is a better
> approach than having dhclient doing ARP ping.
Those are quite different tasks. I would compare wpa_cli monitor to
dhclient following rtnetlink IFLA_OPERSTATE changes internally. To me,
the second one sounds like a better way of noticing when there may be
need for fetching new IP address.
ARP ping just an optimization that could be used to avoid full DHCP
negotiation if the current network setup has not actually changed. It
does not (unless done with polling which would suck) work as a mechanism
for figuring out when DHCP may need to run again.
> 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.
wpa_supplicant does not, and cannot, know whether the DHCP needs to be
run again when roaming from one BSS to another one even in the same ESS
(same SSID). Even re-authentication back to the same BSS without
re-association may result in need to run DHCP again (e.g., if VLAN
assignment changed). All this has to happen at the IP layer, i.e., above
wpa_supplicant. wpa_supplicant does know (and will broadcast this
through IFLA_OPERSTATE in most cases; the re-auth without re-association
may be interesting corner case that needs further work) when the network
configuration may have changed, but not all these cases really need DHCP
to be run again.
I would like to have a DHCP client that will verify (e.g., via ARP ping
of the default gateway) whether the network is still reachable with
current configuration every time the operation state (IEEE 802.1X port
in many cases) or BSSID (if using wireless interface) changes. If not,
it would run DHCP negotiation again.
The configuration of static IP vs. DHCP depending on the SSID is
something that would likely live somewhere else than either dhclient or
wpa_supplicant. If the OS (as in Linux distro, etc.) supports per
SSID/network IP configuration, there would likely be an additional
daemon that would follow WEXT netlink messages and update IP
configuration (and run/kill dhclient) based on new associations. This
daemon would not need to care about operstate/IEEE 802.1X port as long
as dhclient knows how to handle it properly (and it can, by checking the
operstate). Wired networks would work without this additional daemon
since there is only going to be one configuration and it is enough to
set the static IP (or run dhclient) only once (again, assuming that
dhclient knows about operstate to handle wired 802.1X).
Jouni Malinen PGP id EFC895FA
More information about the HostAP