Turns out there are dhcp servers that ignore DHCPREQUEST messages when
authorflorian <florian@openbsd.org>
Sat, 6 Mar 2021 18:33:44 +0000 (18:33 +0000)
committerflorian <florian@openbsd.org>
Sat, 6 Mar 2021 18:33:44 +0000 (18:33 +0000)
commit8baf56acd60933f2fead38af0797a5fb2fdc06f2
tree364cbe7e635c8522046bfc727ec137ce474f8dae
parent43f1a0ea92eae1e5a469efe8479247b0f2a8a757
Turns out there are dhcp servers that ignore DHCPREQUEST messages when
they don't like them instead of sending a DHCPNAK. Found the hard way
by benno who didn't want to wait 127 seconds.

Due to another bug dhcpleased would have exit through a fatal() in the
frontend process if he had waited long enough for a Rebooting -> Init
transition because we didn't deconfigure our IP address and thus
didn't close our UDP socket. Upon configuring a new IP address we would
open a new UDP socket send it to the frontend which would then fatal()
due to an unexpected fd passed in.

Aproporiate timings are rather underspecified in RFC 2131. Instead of
doing an exponential backoff up to 64 in the "Rebooting" and
"Requesting" state only go up to 2 for a total of 3 packets and total
timeout of 3 seconds before going into "Init" state and sending a
DHCPDISCOVER.

To prevent the fatal() in the frontend process we reshuffle the state
transition into the "Init" state and deconfigure the IP when
appropriate.
sbin/dhcpleased/engine.c