DHCP-ing WPA links

~~~~~~~~~~~~~~~~~~

During WPA initialization, the link goes "up" right before EAPOL exchange,

and there is no notification of any kind that the encryption keys have been

installed. If dhcp gets started on link-up event, it is likely to send its

first packet before the link is fully operational, losing it.

Synchronizing EAPOL and DHCP exchange properly requires a combined tool,

or some sort of tight integration between wsupp and ifmon.

wpa_supplicant leaves the issue open, relying on a third-party DHCP with

no apparently link-ready notifications.

Any dhcp implementation following RFC 951 closely will mask the problem due

to mandated retransmits and long timeouts. After losing the first packet,

dhcp will wait off its retransmit timeout (which is often way longer than

the time needed to complete EAPOL exchange) and send the second packet,

leasing ip successfully in most cases.

Running dhcp under wpa

~~~~~~~~~~~~~~~~~~~~~~

One possible solution is to let the supplicant spawn dhcp right after the

keys have been uploaded. It would provide a perfect synchronization, and

the supplicant would become much easier to use as a stand-alone tool.

Downside 1: this would limit interface configurability a lot, realistically

down to the assumption that any WPA interface is always a dhcp-configured

uplink.

Downside 2: renewing DHCP leases. Unless dhcp is a long-running process

itself (not desirable), something has to watch lft and restart it.

Downside 3: large disparity between wired and wireless links.

Signalling link readiness

~~~~~~~~~~~~~~~~~~~~~~~~~

Another option is to make the supplicant signal link readiness somehow

to interface monitor, letting it decide whether or not to run dhcp.

This would remove wired/wireless disparity and make lease renewal much

easier.

Downside: requires tight integration between the supplicant and the link

monitoring tool. Neither RTNL nor GENL support this kind of signalling,

so it has to go through some other channel which both tool must be ready

to use.

# This option has been implemented with ifmon and wsupp. To signal link

# readiness, wsupp sends a pre-configured packet to ifmon's control socket.

Phasing out DHCP on wireless links

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DHCP itself makes little sense in the context of WPA links. DHCP was made

for bus-like or ether-like decentralized networks, where the host could

connect at will and without knowning where the "server" is. In this kind

of environment broadcasting request for address and waiting for somebody

to reply did make sense.

In contrast, WPA link is effectively point-to-point and connects the host

to a strictly controlled, centralized network. The host cannot connect at

will and become a part of the network, it must first ask permission to do

so via EAPOL. Authenticator (AP) that gives the permission to connect could

just as well give the host some address to use. And AP knows when the host

disconnects, so there's no point in renewing leases.

Downside: not a part of 802.11, so only really an option between a custom

AP and a custom supplicant.

If the custom implementation will retain EAPOL or something resembling EAPOL,

the AP should send address(-es) in packet 3/4 alongside the initial GTK.