I don't know if this is related with a specific dhclient version, but it is just ignoring the leasetime sended by the dhcp server and choosing a value itself. I made this test on a gentoo machine using both dhclient and dhcpcd. I take the dump using dhcpdump. You can see on the logs that dhclient just ignores the value, but dhcpcd doesn't. The value choosen by dhclient is not random. It is around 40% of the lease time, but every time I run it, it uses a new one. Reproducible: Always Steps to Reproduce: 1. dhclient -v 2. 3. Actual Results: It choose a "random" leasetime. Expected Results: It should use the leasetime sended by dhcp server.
Created attachment 275405 [details] dhclient output
Created attachment 275407 [details] dhclient log made by dhcpdump
Created attachment 275409 [details] dhcpcd output
Created attachment 275411 [details] dhcpcd log made by dhcpdump
Created attachment 275413 [details] dhclient config
Created attachment 275415 [details] dhcpcd config
The confusion here is that dhclient and dhcpcd are reporting different variables: former is reporting renewal time, and the latter is reporting lease expiration time. Those are not the same thing: the renewal time is when the client will make a request to extend the lease, so it comes before the actual lease expiration to make sure there is plenty of time to receive an answer from the server before its leased IP becomes invalid. I believe the small amount randomness in the renewal time is actually on purpose, so if you've got a big cluster of hosts doing netboot with dhcp they won't all hit the dhcp server at the same time (at least after initial bootup). Does that make sense to you?
Hello Wormo! Thank you very much for your explanation. Now it makes sense to me. In the end I think the problem I'm having is not related with this. Again, thank you!
