dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2020-07-03T08:26:11Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/21Consider setting IP Type of Service to 0 by default, or perhaps make it confi...2020-07-03T08:26:11ZThomas MarkwalderConsider setting IP Type of Service to 0 by default, or perhaps make it configurablefrom [RT 49242](https://bugs.isc.org/Ticket/Display.html?id=49242)
```
Hello ISC,
Linux systems (Ubuntu 16.04) fail to connect to various hotels with wifi as a result of the DHCPDiscover message being sent by dhclient. The same laptop ...from [RT 49242](https://bugs.isc.org/Ticket/Display.html?id=49242)
```
Hello ISC,
Linux systems (Ubuntu 16.04) fail to connect to various hotels with wifi as a result of the DHCPDiscover message being sent by dhclient. The same laptop using MSWindows connects with the hotels without a problem. This has been observed at multiple locations.
The problem was isolated by making the DHCPDiscover packet sent by dhclient match the DHCPDiscover packet sent by MSWindows. It was found that affecting difference was that dhclient generated a non-zero value for the TOS UDP field. Commenting out the setting of ip.ip_tos in packet.c so that the field remained zero fixed the problem:
dhcp-4.4.1/common:
$ diff packet.c packet.c.orig
150c150
< // ip.ip_tos = IPTOS_LOWDELAY;
---
> ip.ip_tos = IPTOS_LOWDELAY;
The hotel's router may have been mis-configured to interpret the TOS field. However, the hotel connects to MSWindows/Apple devices. As a result, open source systems such as Ubuntu (Linux) gain a reputation of being unreliable. (My wife wants/needs to use MS/Apple systems as result)
I would like to suggest that if the default DHCP message content generated by MSWindows/Apple adheres to standards, then have the default DHCP message content from open source systems (linux) match bit for bit. Sniff packets and compare to verify. Such practice would assure that open source connectivity (linux) is no less reliable than commercial device connectivity.
Thank you,
Glen Wetzel
FYI: https://en.wikipedia.org/wiki/Type_of_service
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/52Server Overrides for ORO For DHCPv6, Similar to Parameter Request List in DHCP?2020-04-27T13:42:02ZNickServer Overrides for ORO For DHCPv6, Similar to Parameter Request List in DHCP?Hello!
I want to be able to override ORO for DHCPv6 the same way you can use parameter request lists in DHCP to send DHCP options that weren't solicited.
An example use case would be in testing adding options to a DHCP server, it's use...Hello!
I want to be able to override ORO for DHCPv6 the same way you can use parameter request lists in DHCP to send DHCP options that weren't solicited.
An example use case would be in testing adding options to a DHCP server, it's useful to be able to blast over whatever DHCP options over the wire without messing around too much with the dhclient between every add, seeing the results in Wireshark. Also, you could imagine if you were trying to migrate to DHCPv6 and you relied on the parameter request list in DHCP, you might not have an obvious route forward.
Is it intentional that you cannot override ORO in the server? If I were to add support for this, would this be something you would potentially want to merge?
Thanks!OutstandingNickNickhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/70Add new option type 'k' to parse_option_code_definition2020-07-03T08:19:08ZThomas MarkwalderAdd new option type 'k' to parse_option_code_definition#68 added new option format type 'k', this could be made available to users for custom options.#68 added new option format type 'k', this could be made available to users for custom options.https://gitlab.isc.org/isc-projects/dhcp/-/issues/73dhclient not releasing IPv6 address2022-03-07T13:13:08ZGhost Userdhclient not releasing IPv6 address---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhclient not releasing the IPv6 address where as IPv4 address release working fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclie...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhclient not releasing the IPv6 address where as IPv4 address release working fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient -6 with regular configuration.
2. Send signal 15 to kill the dhclient process.
3. Observed release of the IP address not happening. The following message only seen from dhclient logs.
`Received signal 15, initiating shutdown.`
**Expected behavior**
As part of signal handling dhclient should call the do_release6 for AF_INET6 family. This will gracefully release IPv6 address and calls the script file also.
Where as, dhclient is gracefully releasing the IPv4 address. We can observe the following logs for the same.
`Received signal 15, initiating shutdown.`
`DHCPRELEASE of <SELF IP ADDRESS> on <INTERFACE NAME> to <DHCP SERVER IP> port 67`
`Killed`
**Environment:**
- ISC DHCP version: isc-dhclient-4.4.1
- OS: Linux CentOS
- Which features were compiled in: dhclient
**Additional Information**
NOT sure this behavior is w.r.to IPv6 architecture only. Would like to make sure not missing things from isc-dhclient side.
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Yes
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration? Don't know
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? NOOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/94DHCP relay agent will not discover interfaces if they are down when dhcrelay ...2022-03-09T19:03:52ZJoe LeVequeDHCP relay agent will not discover interfaces if they are down when dhcrelay startsCurrently, dhcrelay will not discover interfaces if they are down at the time the relay agent starts up. If the interface(s) are down at the moment dhcrelay enumerates the interfaces, yet they get brought up any time later, the relay wil...Currently, dhcrelay will not discover interfaces if they are down at the time the relay agent starts up. If the interface(s) are down at the moment dhcrelay enumerates the interfaces, yet they get brought up any time later, the relay will discard packets received on these interfaces and log the message, `Discarding packet received on <iface_name> interface that has no IPv4 address assigned`.
With this patch, the relay agent will discover all configured interfaces, whether or not they are up at the time the relay agent starts. Thus, the state of the configured interfaces can be down when the relay agent starts and brought up during the lifetime of the relay agent process, and the relay agent will relay packets as expected; it will not discard them. A DHCP relay agent shouldn't ignore a configured interface if the interface happens to be down when it starts up.
The patch is the addition of one line in common/discover.c, after line 638.
Current code:
```c
/* Skip non broadcast interfaces (plus loopback and
point-to-point in case an OS incorrectly marks them
as broadcast). Also skip down interfaces unless we're
trying to get a list of configurable interfaces. */
if ((((local_family == AF_INET &&
!(info.flags & IFF_BROADCAST)) ||
#ifdef DHCPv6
(local_family == AF_INET6 &&
!(info.flags & IFF_MULTICAST)) ||
#endif
info.flags & IFF_LOOPBACK ||
info.flags & IFF_POINTOPOINT) && !tmp) ||
(!(info.flags & IFF_UP) &&
state != DISCOVER_UNCONFIGURED))
continue;
```
Proposed patch:
```c
/* Skip non broadcast interfaces (plus loopback and
point-to-point in case an OS incorrectly marks them
as broadcast). Also skip down interfaces unless we're
trying to get a list of configurable interfaces. */
if ((((local_family == AF_INET &&
!(info.flags & IFF_BROADCAST)) ||
#ifdef DHCPv6
(local_family == AF_INET6 &&
!(info.flags & IFF_MULTICAST)) ||
#endif
info.flags & IFF_LOOPBACK ||
info.flags & IFF_POINTOPOINT) && !tmp) ||
(!(info.flags & IFF_UP) &&
state != DISCOVER_UNCONFIGURED &&
state != DISCOVER_RELAY))
continue;
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/129Subnet parameters should be overridable per-host2022-01-13T11:20:30ZPhilip PrindevilleSubnet parameters should be overridable per-host---
name: Per-host subnet overrides
about: It's occasionally useful to drop an option on a one-off basis in a group
---
**Initial Questions**
If you have a configuration like:
```
authoritative;
log-facility daemon;
default-lease-tim...---
name: Per-host subnet overrides
about: It's occasionally useful to drop an option on a one-off basis in a group
---
**Initial Questions**
If you have a configuration like:
```
authoritative;
log-facility daemon;
default-lease-time 3600;
max-lease-time 86400;
option domain-name "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.128 192.168.1.254;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
default-lease-time 43200;
max-lease-time 43200;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option ntp-servers 192.168.1.40;
}
...
# and a bunch of static allocations in as "host" reservations
host switch {
hardware ethernet 00:01:02:03:04:05;
fixed-address 192.168.1.2;
option host-name "switch";
}
...
# and an alarm system that should never have a default-route
host alarm {
hardware ethernet 00:01:02:0a:0b:0c;
fixed-address 192.168.1.8;
option host-name "alarm";
option routers none;
}
```
In this case, it's easier to default all of the hosts as getting a default-route, except for one where that isn't the case and call that out explicitly.
In the special case of IPv4 routers, you can set it to "0.0.0.0" and an ISC-DHCP client will reject this value, but the same is not true of many other DHCP clients, including the built-in one in NetworkManager, and indeed this should be handled server-side anyway ("Be conservative in what you send...").
**Prior Discussion**
This has been brought up on the `#isc-dhcp` IRC channel as well as the `dhcp-workers` mailing list.
**Limitations/Genesis**
If I have a subnet with 250 hosts, 249 of which should receive a default route, and 1 of which shouldn't, I shouldn't have to write 250 `host` definitions... and if I'm using dynamic allocations, this isn't even possible. Configuration should be powerful, simple, and easy.
**Desired Solution**
Be able to override subnet defaults on a per-host basis.
**Alternatives**
There really aren't any. Even if I were to use classes as a shorthand, I'd still need to default all hosts on my network.
**Additional context**
None
**Funding its development**
See below.
**Participating in development**
I'd be willing to drive the development of this feature and do most of it myself, but I might need some guidance navigating the code base as I'm not well-versed in it.
**Contacting you**
Comments on this issue, or as `philipp@redfish-solutions.com` via email, or as `philipp64` on IRC (`freenode.org`).https://gitlab.isc.org/isc-projects/dhcp/-/issues/136Implement the generate() operator.2020-11-12T20:42:26ZXavier G.Implement the generate() operator.---
name: Implement the generate() operator.
about: Implement the generate() operator as part of dhcp-eval. generate() is similar
to execute() in that it executes an external program. However, unlike execute(),
generate() is a...---
name: Implement the generate() operator.
about: Implement the generate() operator as part of dhcp-eval. generate() is similar
to execute() in that it executes an external program. However, unlike execute(),
generate() is a data expression: it reads up to 1024 bytes from the standard output
of the resulting child process and makes them available as a C string. It can therefore
be combined with substring(), concat() and other similar operators for maximum
flexibility. Like execute(), generate() can be disabled through ./configure --disable-generate.
---
Note: this feature request probably rings a bell; it is actually a follow up to https://bugs.isc.org/Public/Bug/Display.html?id=48316 as I am still interested in this feature.
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
=> Sure enough for me to write a patch back in October 2018; according to grep, the situation has not evolved since then.
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration?
=> My understanding of the Kea project is that it provides a DHCP server, not a DHCP client. Although my patch extends dhcp-eval, a part common to both iscp-dhcp-server and isc-dhcp-client, it was designed with isc-dhcp-client in mind.
- Are you sure what you would like to do is not possible using some other mechanisms?
=> The most common approach to emulate a generate() operator consists in using a separate tool (scripts, Puppet, SaltStack, Ansible, etc.) to re-generate the ISC DHCP client configuration file. This approach is clearly hackish and non-perennial.
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
=> No, it was only briefly discussed on https://bugs.isc.org/Public/Bug/Display.html?id=48316
**Is your feature request related to a problem? Please describe.**
This feature is indeed related to a problem: in 2018, we stumbled upon an ISP which expects a particular value for options 90 or 11 (authentication). This value is computed using a proprietary, ISP-specific algorithm (it involves random
salts, MD5 hashing and a password... far from rocket science, but definitely ISP-specific) and should be renewed systematically or at least frequently.
Moreover, this algorithm is likely to change often enough to discourage its implementation in C within dhclient/dhcpd. generate() enables users to delegate tricky value generations to external programs that can be implemented using higher-level languages and can be updated frequently.
**Describe the solution you'd like**
I am willing to update the patch I had submitted back in October 2018 and make a pull request out of it.
To this end, I need:
- confirmation that this feature could make its way into isc-dhcp
- a 'project allocation'
**Describe alternatives you've considered**
It would be tempting to look for another DHCP client, or even write a small one dedicated to the ISP mentioned above. That would however be quite frustrating as the dhcp-eval mechanism has been around for years and is so close to offer a solution to the encountered problem.
**Funding its development**
I consider that I should either give time (i.e. code/patches) or money. In this case, I chose the former.
**Participating in development**
Are you willing to participate in the feature development?
=> Yes, obviously.
ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions?
=> Yes, totally.
Are you willing to test an unreleased engineering code?
=> Yes, I am.
**Contacting you**
Email (as provided by registering to ISC's Gitlab instance) is fine.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/144Cisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to sa...2020-12-03T15:37:35ZGunnar HaslingerCisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to same VPN-Clients**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the sam...**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the same IP as it got yesterday. Our idea is to provide an IP-lease-Pool big enough to have pseudo-static Client-IP-Addresses. The address the client gets on it's first connect should be the same it gets the following days/months.
**Currently VPN-Clients are not assigned the same IP-Address, because:**
- Cisco ASA is acting as DHCP-Client for the VPN-Clients
- The Client-MAC of all VPN-Clients is the same (the ASA MAC)
The Client-UID (Client identifier) sent by the ASA is a combined-string of `"cisco-$MAC-$Hostname$Counter-inside"`.
- For example: `cisco-0050.5680.4b04-ClientA4567-inside`
- The Prefix "cisco" + MAC-Address of the Cisco-ASA is always the same: `cisco-0050.5680.4b04`
- The Hostname (e.g. "ClientA") is the real (unique) Hostname of our Client-Machines
- The counter counts up on every connection.
- Suffix "-inside" is always the same
- If "ClientA" disconnects and connects again it will be like `cisco-0050.5680.4b04-ClientA4568-inside` (the last digits count up)
- There seem to be no way to configure the Cisco ASA to not count up the Client-UIDs last digits on each connection
- We tried to use Option "`ignore-client-uids true;`" to reassign the same IP-Address - but this does not work, because without UID only the MAC-Address is used to re-assign the IP-Address, but all Clients have the same (Cisco ASA) MAC-Address.
**Are there any suggestions?**
- If there is no solution for this scenario, we are interested to implement an new ISC DHCPd Option "`hostname-as-uid true;`" to create the possibility to address this scenario.
- This option "`hostname-as-uid true;`" could be used like the existing "`ignore-client-uids true;`" Option, but instead of not saving the Client-UID we would override the received Client-UID with the received hostname-option.
- All functionality like storing the uid to the lease-file, checking if there is a lease for the client with the given Client-UID etc... will be done with the "replaced uid" (= Hostname) instead of the real received Client-UID.
- Are there any other suggestions or comments on this?
- Is there interest to accept a merge request if we implement such a feature?Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/146Add support for raw IP interface type2020-12-03T10:15:34ZFrancis DupontAdd support for raw IP interface typeSee !66 (issue created to host it).See !66 (issue created to host it).4.5.0-betaFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/164Allow update-conflict-detection to be specified at class scope2022-09-07T12:48:23ZThomas MarkwalderAllow update-conflict-detection to be specified at class scopeThe implementation of DSMM in 4.4.0, limited the scope of update-conflict-detection to global scope only. We have a request from a support customer to expand to support at least class-scope:
https://support.isc.org/Ticket/Display.html?...The implementation of DSMM in 4.4.0, limited the scope of update-conflict-detection to global scope only. We have a request from a support customer to expand to support at least class-scope:
https://support.isc.org/Ticket/Display.html?id=17904
Customer is willing to use a patch, if we can develop one.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/179Need to add support for structured options2022-03-09T19:11:17ZBen DonnetteNeed to add support for structured options---
name: Support for dhcp structured options
about: Dealing with eg. MAP-T configuration options by generating several environment variables
---
**Some initial questions**
- Are you sure your feature is not already implemented in the ...---
name: Support for dhcp structured options
about: Dealing with eg. MAP-T configuration options by generating several environment variables
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
It was not last time I had a look.
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration?
- Are you sure what you would like to do is not possible using some other mechanisms?
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
**Is your feature request related to a problem? Please describe.**
I'm trying to use dhcp to configure a MAP-T CE. This involves the DHCPv6 options as described in the RFC 7498. The idea is to then push the options as environment variables useable in shell scripts called upon lease recepit.
If we take the S46 rule (option 89) as an example and use the S46RULE prefix, one could expect the following environment variables generated :
S46RULE_FLAG
S46RULE_EALEN
S46RULE_IPV4PREFIX (network notation eg. 192.168.1.0/24)
S46RULE_IPV6PREFIX
S46RULE_OPTIONS (the latter giving rise to deeper structures).
This is actually what udhcpc already does (probable contribution from OpenWRT).
**Describe the solution you'd like**
Upon receipt of an option, an environmen,t variable gets filled when a text representation is relevant. For structured options, the idea is to mimic the structure with the generation of autrtomatic environment variable using a "_" (underscore) syntax.
**Describe alternatives you've considered**
The project I'm on would not be easy to migrate to other dhcp clients.
**Additional context**
See RFC 7498
**Funding its development**
I could implement the feature.
**Participating in development**
I could implement the feature. Of course complying to the architecture team's directives.
**Contacting you**
E-mail, github woiuld be relevant.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/194resolvconf support is missing in dhclient2022-03-09T19:00:02Zonehalf3544resolvconf support is missing in dhclientBy default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/...By default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/openvpn, which set up DNS servers from the private network). The natural solution is the usage of resolvconf, which manages such updates from multiple sources and merges them into /etc/resolv.conf
Since this is more like a feature request, it was suggested that this should be fixed here (https://bbs.archlinux.org/viewtopic.php?pid=1969134).
Would such PR be accepted? The changes are quite trivial..
Thanks.
**Describe the bug**
dhclient overwrites the /etc/resolv.conf blindly, disregarding the fact that it could have been updated by other (dhcp) clients
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient with default config
2. Modify /etc/resolv.conf by any means
3. Wait for the lease renewal on the dhclient interface
4. Observe the contents of the /etc/resolv.conf
**Expected behavior**
/etc/resolv.conf contents should be preserved somehow. Proposed way is to use resolvconf for that.
**Environment:**
dhclient --version
isc-dhclient-4.4.2
- OS: ArchLinux
Linux laptop_name 5.12.7-arch1-1 #1 SMP PREEMPT Wed, 26 May 2021 22:03:57 +0000 x86_64 GNU/Linux
pacman -F dhclient
core/netctl 1.24-1
usr/lib/netctl/dhcp/dhclient
**Additional Information**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
It is not - https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L80
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
Did not check, but would prefer to keep original dhclient
- Are you sure what you would like to do is not possible using some other mechanisms?
Using hooks, yes, but feature implementation is better to be done as close to the source as possible
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
arch linux forum - https://bbs.archlinux.org/viewtopic.php?pid=1969134#p1969134
**Is your feature request related to a problem? Please describe.**
I'm frustrated when my VPN tunnel DNS server IP is overwritten with the ISP dhcp
**Describe the solution you'd like**
Check if /usr/bin/resolvconf exists and use it if it does
**Describe alternatives you've considered**
switch to a different dhcp client
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
I could provide the patch once I can fork the project here
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
yes
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.
onehalf3544@gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/290The timer of dhclient doesn't work if date changed2023-08-30T12:51:28Zqianfan ZhaoThe timer of dhclient doesn't work if date changedHi:
dhclient use `gettimeofday(&cur_tv, NULL);` get current time and use this wall time as timer resource. So the timer resource is not valid when the date is changed.
Next is the dhclient logs when no cable plugged in:
```
Jan 9 07...Hi:
dhclient use `gettimeofday(&cur_tv, NULL);` get current time and use this wall time as timer resource. So the timer resource is not valid when the date is changed.
Next is the dhclient logs when no cable plugged in:
```
Jan 9 07:31:48 buildroot daemon.info dhclient: Internet Systems Consortium DHCP Client 4.4.3
Jan 9 07:31:48 buildroot daemon.info dhclient: Copyright 2004-2022 Internet Systems Consortium.
Jan 9 07:31:48 buildroot daemon.info dhclient: All rights reserved.
Jan 9 07:31:48 buildroot daemon.info dhclient: For info, please visit https://www.isc.org/software/dhcp/
Jan 9 07:31:48 buildroot daemon.info dhclient:
Jan 9 07:31:49 buildroot daemon.info dhclient: Listening on LPF/FE0/0c:fe:5d:42:5d:eb
Jan 9 07:31:49 buildroot daemon.info dhclient: Sending on LPF/FE0/0c:fe:5d:42:5d:eb
Jan 9 07:31:49 buildroot daemon.info dhclient: Sending on Socket/fallback
Jan 9 07:31:49 buildroot daemon.info dhclient: DHCPDISCOVER on FE0 to 255.255.255.255 port 67 interval 4
Jan 9 07:31:53 buildroot daemon.info dhclient: DHCPDISCOVER on FE0 to 255.255.255.255 port 67 interval 4
Jan 9 07:31:57 buildroot daemon.info dhclient: DHCPDISCOVER on FE0 to 255.255.255.255 port 67 interval 6
Jan 9 07:32:03 buildroot daemon.info dhclient: DHCPDISCOVER on FE0 to 255.255.255.255 port 67 interval 14
<date is changed after this>
```
It should print sometings like this and try again later:
```
dhclient: No DHCPOFFERS received.
dhclient: No working leases in persistent database - sleeping.
```
But after the date changed, dhclient hangup forever.