dhcp: a client that has asked enough reverts to INIT
A spent retransmission budget ended the exchange: timer answered Failed
and left the client in SELECTING or REQUESTING, holding a half-finished
exchange nothing could take further. RFC 2131 s.3.1 step 5 is explicit
about the DHCPREQUEST -- "If the client receives neither a DHCPACK or a
DHCPNAK message after employing the retransmission algorithm, the client
reverts to INIT state and restarts the initialization process" -- and
s.3.2 step 3 says the same of a client verifying a remembered address.
For the DHCPDISCOVER the specification gives no bound at all: s.4.1
bounds the delay between retransmissions and not their number, and s.3.1
step 3 says only that the client times out and retransmits. Either way
a client that stops asking has recorded nothing, which is INIT.
So the pure machine no longer stops: it goes back to the start, drops
what it was holding, and hands the driver Restart, which already meant
begin again with a fresh transaction id. Figure 5 has no arrow that
ends a client's life, and now neither has this reducer, bar the two
lease-holding phases the next commit is about.
When to stop asking is a policy, and it moves to the driver that has a
clock and a user to answer to. Dhcp_eio.drive, lease and renew take a
~sends budget, eight by default -- a DORA's two phases at the four
attempts s.3.1 step 5 gives as its example -- and lease shares one
budget across every restart, so a client nobody answers stops rather
than beginning again for ever. A caller that wants the old timing
passes ~sends:4.
Two pins retired, two left.