Bug 1729211 - dhclient fails to renew IP address lease after system time changes
Summary: dhclient fails to renew IP address lease after system time changes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dhcp
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Pavel Zhukov
QA Contact: Ondrej Mejzlik
Mariya Pershina
URL:
Whiteboard:
Depends On:
Blocks: 1755139 1741517 1743192
TreeView+ depends on / blocked
 
Reported: 2019-07-11 15:20 UTC by Pavel Zhukov
Modified: 2020-04-28 16:55 UTC (History)
3 users (show)

Fixed In Version: bind-9.11.12-4.el8, dhcp-4.3.6-37.el8
Doc Type: Bug Fix
Doc Text:
.`dhclient` no longer fails to renew the IP address after system time changes Previously, if the system time changed, the system could lose the IP address assigned due to the removal by the kernel. With this update, `dhclient` uses monotonic timer to detect backward time jumps and issues the `DHCPREQUEST` message for lease extension in case of discontinuous jump in the system time. As a result, the system no longer loses the IP address in the described scenario.
Clone Of:
Environment:
Last Closed: 2020-04-28 16:55:31 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1858 None None None 2020-04-28 16:55:38 UTC

Description Pavel Zhukov 2019-07-11 15:20:57 UTC
This bug was initially created as a copy of Bug #1093803

I am copying this bug because: 



Description of problem:

It seems that dhclient is affected by system "wall clock" time changes and can - in some (but 100% reproducible) cases - disconnect the interface completely (remove its address).

Version-Release number of selected component (if applicable):
dhclient-4.2.5-27.el7

How reproducible:
always


Steps to Reproduce:
1. set up an isolated private network with dhcp server using ie. 1 minute lease time
2. on a separate system (machine) that's connected to the dhcp server network, stop NetworkManager and the network service, kill any possible dhclient instances
3. bring the target interface up manually, start dhclient manually
4. verify (using tcpdump) that dhclient refreshes the address every ~1 minute
5. between dhcp requests, advance the system time by an amount larger than the lease time, ie. 2 days
6. observe dhclient sending two requests, but working like normal after that, with ~1 minute pauses
7. roll back the system time by 2 days
8. observe no further dhcp requests, notice ipv4 address removal after ~2 minutes, disconnecting any active ssh sessions
9. while connected to the machine via a physical TTY, note the dhclient process still running, with no special log messages, the last one being about future renewal


Actual results:
dhclient is affected by system time changes

Expected results:
dhclient can operate independently on system time
(or at least survive large jumps)

Additional info:
This issue was originally found and described in bug 1034737 as a possible NetworkManager problem. Since then, NM was altered to use CLOCK_BOOTTIME, but the issue remained, so I tried it without NM and was still able to reproduce it, using the steps described above.

The steps are a simplification of several test cases done by the audit-test suite, which we use for Common Criteria Certification testing. An example reproducer, extracted from the suite, is attached.

Comment 16 errata-xmlrpc 2020-04-28 16:55:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1858


Note You need to log in before you can comment on or make changes to this bug.