Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up.
Describe the bug Whilst connecting a host running dhclient of version = 4.4.1 to a network with DHCP server temporarily disabled (a brief scheduled maintenance). The observed behaviour (please find the details below) hasn't been exactly anticipated and we haven't seen any corresponding entry in the 4.4.2 release notes.
To Reproduce Dhclient config:
timeout 131;
retry 33;
reboot 9;
select-timeout 3;
initial-interval 2;
interface "eth1" {
request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, ntp-servers, vendor-encapsulated-options, dhcp-renewal-time, dhcp-rebinding-time;
require subnet-mask;
}
Current time: Wed 03 Feb 2021 12:33:20 PM PST
Leases file - case 1 with the lease expiration set in half an hour time:
lease {
interface "eth1";
fixed-address 10.1.1.92;
option subnet-mask 255.255.255.128;
option dhcp-lease-time 3600;
option routers 10.1.1.1;
option dhcp-message-type 5;
option dhcp-server-identifier ....;
option domain-name-servers ....
option domain-name "....";
renew 3 2021/02/03 13:02:23;
rebind 3 2021/02/03 13:03:23;
expire 3 2021/02/03 13:05:23;
}
Observation: Starts with DHCP discover (why not with DHCP request whilst the lease is still valid?), and continues search for a DHCP Server. according to the timings set-up in the config. Now let's set the expiries for renew, rebind and expire to tomorrow date so leases file would resemble as follows (leases' database case 2):
lease {
interface "eth1";
fixed-address 10.1.1.92;
option subnet-mask 255.255.255.128;
option routers 10.1.1.1;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option domain-name-servers ...;
option dhcp-server-identifier ...;
option domain-name "...";
renew 4 2021/02/04 13:10:16;
rebind 4 2021/02/04 13:11:16;
expire 4 2021/02/04 13:13:16;
}
It starts with 3 DHCP Requests (expected I daresay - we wonder why it hasn't started with DHCP requests with the sooner lease expiration date & time. It stops sending out the DHCP discover after the timeout to wake up and start sending them out around the midnight when the date will become 4th of February 2021 (unexpected).
Would there be something we do not fully realise? Is the afore an expected behaviour? If so would there be a way for a continuous DHCP discovery, whilst formerly leased IP would be in use after, timeout = 131 [s] passing and no response from a DHCP server?
Expected behavior
- The behaviour ought to be consistent for both cases 1 & 2 :
- As in both cases: 1 &2 the lease is still valid dhclient should start with DHCP Request
- When the lease expiration date is set for some day in the future the DHCP Discover should not stop after timeout time
Environment:
-
ISC DHCP version: v4.4.1
-
OS: Ubuntu 20.04 x64
-
Which features were compiled in
Additional Information Please see steps to reproduce
Some initial questions
- Are you sure your feature is not already implemented in the latest ISC DHCP version? We haven't seen any corresponding entry in the 4.4.2 release notes.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time to consider migration? N/A as kea is a server
- Are you sure what you would like to do is not possible using some other mechanisms? If there is another mechanism, other than wiping out leases' DB at the boot time I would be extremely interested in getting know about it.
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? Not yet. I shall ask the question with the link to this particular issue. I deem having a record is mutually beneficial.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] It is very important to describe what you would like to do and why?
Describe the solution you'd like A fix in a subsequent maintenance release.
Describe alternatives you've considered It is more of a sighting at this stage and perhaps originating in some deficiency in the existent documentation. We are uncertain at this stage where the problem lies. It looks like some flaw in the logic implementation. Additional context N/A
Funding its development Yup, I would be happy to donate.
Participating in development I would be willing to help with testing a WIP, patch or unreleased code.
Contacting you e-mail: butterfly_tm666@yahoo.com; tomasz.motyl@se.com
With my best wishes Tomasz Motyl