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.