Bug 1729211

Summary: dhclient fails to renew IP address lease after system time changes
Product: Red Hat Enterprise Linux 8 Reporter: Pavel Zhukov <pzhukov>
Component: dhcpAssignee: Pavel Zhukov <pzhukov>
Status: CLOSED ERRATA QA Contact: Ondrej Mejzlik <omejzlik>
Severity: unspecified Docs Contact: Mariya Pershina <mpershin>
Priority: unspecified    
Version: 8.1CC: mpershin, omejzlik, thozza
Target Milestone: rcKeywords: Patch, Reproducer, TestCaseApproved
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:55:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1741517, 1743192, 1755139    

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