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.

0 files changed, 0 insertions, 0 deletions