dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2023-08-30T12:51:28Zhttps://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.https://gitlab.isc.org/isc-projects/dhcp/-/issues/207Use the PACKET_IGNORE_OUTGOING socket option for dhclient2022-04-04T20:12:59ZMarc RichardsUse the PACKET_IGNORE_OUTGOING socket option for dhclientOn Linux, dhclient opens a packet socket to facilitate low-level operations. This means that it has access to all the packets that are sent or received on a given network interface. A BPF filter is used to efficiently ignore irrelevant p...On Linux, dhclient opens a packet socket to facilitate low-level operations. This means that it has access to all the packets that are sent or received on a given network interface. A BPF filter is used to efficiently ignore irrelevant packets, however there is still some kernel overhead involved in filtering those packets. In the majority of use cases, the overhead is negligible, but under [very extreme circumstances](https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/#_7-the-case-of-the-nosy-neighbor) that overhead can be as much as 6%.
Linux 4.20 and newer supports a new socket option ([PACKET_IGNORE_OUTGOING](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa788d986a3aac5069378ed04697bd06f83d3488)) that allows outgoing packets to be ignored for a packet socket with even greater efficiency. As best as I can tell, dhclient is only interested in incoming packets, so it may be possible to add this feature without any large changes or loss of functionality (I hope).
I believe something similar exists for BSD distos as well.
I am willing to test and verify unreleased engineering code for this feature and contribute whatever feedback I can.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/205ipv6 dhcp replies do not arrive at dhclient2022-03-09T19:14:32Zudovdhipv6 dhcp replies do not arrive at dhclient**Describe the bug**
We run isc dhclient to do ipv6 prefix delegation:
`dhclient -P -6 ppp0 -d -v`
We see packets bing transmitted (in the cli and in tcpdump if we are monitoring).
We see replies arrive at the box but do NOT see these b...**Describe the bug**
We run isc dhclient to do ipv6 prefix delegation:
`dhclient -P -6 ppp0 -d -v`
We see packets bing transmitted (in the cli and in tcpdump if we are monitoring).
We see replies arrive at the box but do NOT see these being processed by dhclient.
These replies and up in the FORWARD iptables rule.
Issue also happens when NO firewall is active.
**To Reproduce**
Steps to reproduce the behavior:
1. see the description.
**Expected behavior**
I'd expect the packet to be recived, dhclient doing some processing and running scripts etc.
**Environment:**
dhcp-client-4.4.2-11.b1.fc34.x86_64
Fedora 34
kernel.org
```
# ip -6 a s dev ppp0
20: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc cbq state UNKNOWN group default qlen 3
inet6 fe80::c5d5:e942:39c7:7eb7 peer fe80::9ecc:83ff:fec6:e7e5/128 scope link
valid_lft forever preferred_lft forever
```
```
# lsof -p 4066992 -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dhclient 4066992 root cwd DIR 254,0 4096 40961 /root
dhclient 4066992 root rtd DIR 254,0 4096 2 /
dhclient 4066992 root txt REG 254,2 2018144 141553 /usr/sbin/dhclient
dhclient 4066992 root mem REG 254,2 53728 22104 /usr/lib64/libnss_files-2.33.so
dhclient 4066992 root mem REG 254,2 1913544 21939 /usr/lib64/libc-2.33.so
dhclient 4066992 root mem REG 254,2 32696 30196 /usr/lib64/libcap-ng.so.0.0.0
dhclient 4066992 root mem REG 254,2 842360 30776 /usr/lib64/ld-2.33.so
dhclient 4066992 root 0u CHR 136,4 0t0 7 /dev/pts/4 (deleted)
dhclient 4066992 root 1u CHR 136,4 0t0 7 /dev/pts/4 (deleted)
dhclient 4066992 root 2u CHR 136,4 0t0 7 /dev/pts/4 (deleted)
dhclient 4066992 root 3u unix 0x000000001f2593f7 0t0 16525445 type=DGRAM (UNCONNECTED)
dhclient 4066992 root 4w REG 254,4 64 251 /var/lib/dhclient/dhclient6.leases
dhclient 4066992 root 5w FIFO 0,8 0t0 16525446 pipe
dhclient 4066992 root 6u IPv6 16524541 0t0 UDP [fe80::c5d5:e942:39c7:7eb7]:dhcpv6-client
```
```
# tcpdump -i ppp0 -vn port 546
dropped privs to tcpdump
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
06:53:09.236781 IP6 (flowlabel 0x7f0d8, hlim 1, next-header UDP (17) payload length: 60) fe80::c5d5:e942:39c7:7eb7.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=b68ba1 (client-ID hwaddr/time type 1 time 394565497 004063f60200) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (IA_PD IAID:0 T1:3600 T2:5400))
06:53:09.469530 IP6 (class 0xc0, hlim 64, next-header UDP (17) payload length: 141) fe80::9ecc:83ff:fec6:e7e5.dhcpv6-server > fe80::c5d5:e942:39c7:7eb7.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=b68ba1 (client-ID hwaddr/time type 1 time 394565497 004063f60200) (server-ID vid 0000058339633a63) (IA_PD IAID:0 T1:3600 T2:5760 (IA_PD-prefix 2001:981:a812::/48 pltime:7200 vltime:7200)) (DNS-server 2001:888:0:6::66 2001:888:0:9::99))
06:53:09.469756 IP6 (class 0xc0, hlim 63, next-header UDP (17) payload length: 141) fe80::9ecc:83ff:fec6:e7e5.dhcpv6-server > fe80::c5d5:e942:39c7:7eb7.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=b68ba1 (client-ID hwaddr/time type 1 time 394565497 004063f60200) (server-ID vid 0000058339633a63) (IA_PD IAID:0 T1:3600 T2:5760 (IA_PD-prefix 2001:981:a812::/48 pltime:7200 vltime:7200)) (DNS-server 2001:888:0:6::66 2001:888:0:9::99))
^C
```
**Describe the solution you'd like**
It appears that the issue is local but what is prohibiting the replies being received?
**Describe alternatives you've considered**
We need ipv6 PD as it is the sole mechanism the ISP gives us ipv6.https://gitlab.isc.org/isc-projects/dhcp/-/issues/185IPv6 dhclient does not accept server provided prefix length2022-03-09T19:12:43ZSunitha HarishIPv6 dhclient does not accept server provided prefix length---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org. If you really need to report it here, please set the confidential
field to true.
**Describe the bug**
IPv6 dhclient does not accept server provided prefix length. It always set it to 128
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient -6 -nw -cf /etc/dhclient.conf -lf /tmp/dhcp/dhclient6-eth0.leases -pf /tmp/dhcp/dhclient6-eth0.pid eth0
2. DHCP server sends the value 64 for prefix-legth
3. The dhclient sets the default value 128 , and ignores the value 64 sent by the server
4. dhclient's new IPv6 ip is not pingable from the dhcp server machine, since the prefix-length is not matching
**Expected behavior**
dhclient must parse the prefix-length sent from the server and set it to the interface
**Environment:**
Internet Systems Consortium DHCP Client 4.4.1
- OS: Linux 5.4.85
**Additional Information**
My /etc/dhcp/dhcpd6.conf is
subnet6 2001:db8:0:2::/64 {
range6 2001:db8:0:2::120 2001:db8:0:2::130;
}
IP set by dhclient is
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 14:0d:4f:68:74:8d brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:0:2::126/128 scope global deprecated dynamic
valid_lft 2590893sec preferred_lft 0sec
inet6 fe80::160d:4fff:fe68:748d/64 scope link
valid_lft forever preferred_lft forever
**Some initial questions**
I explored the dhclient code in the isc project and saw that the prefix length is set to 128 by default. What is the reason for the hardcoding?
I also saw a forum where this is discussed : https://kb.isc.org/docs/aa-01141
When is the fix is planned to come? My product is using this dhclient and it needs this change at the earliest
**Is your feature request related to a problem? Please describe.**
My product is required to accept the dhcp server sent prefix-length.
**Describe the solution you'd like**
Parse the prefix-length at the dhclient.c and set the {new_ip6_prefixlen} at the dhclient script
**Describe alternatives you've considered**
Alternative is to again hardcode the prefix-length to other value at my dhclient environment using --address-prefix-len option. But that again does not help since its again a hardcoded value
**Participating in development**
No
**Contacting you**
sunithaharish04@gmail.comOutstandinghttps://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/208isc-dhcp-client adopts server settings despite them not "request"ed2022-03-09T19:02:00ZCarlos Henrique Lima Melaraisc-dhcp-client adopts server settings despite them not "request"ed**Bug Description**
Hi, this is a bug well-known bug in Debian BTS (see [#407336](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407336), [#672232](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232) and [#553023](https://bugs....**Bug Description**
Hi, this is a bug well-known bug in Debian BTS (see [#407336](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407336), [#672232](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232) and [#553023](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553023)), but it
still affects the dhclient/dhclient-scripts. The problem is that the dhclient "accepts"
options provided by the dhcp server even when they're not declared in `dhclient.conf`.
For example, I've removed the `ntp-servers` servers from my `dhclient.conf`, but the
dhclient still set `new_ntp_servers` variable and the dhclient-script that deals with
ntp configuration sets it as the ntp server.
**To Reproduce**
Steps to reproduce the behavior:
1. A DHCP server that sends options even if they're not requested
2. A dhclient version isc-dhclient-4.4.1 that doesn't request `ntp-servers` in `dhclient.conf`
3. Allowing the `debug` script show the following variables set by dhclient:
```
Thu Feb 14 08:12:04 -02 2019: entering /etc/dhcp/dhclient-enter-hooks.d, dumping variables.
reason='PREINIT'
interface='eth0'
--------------------------
Thu Feb 14 08:12:04 -02 2019: entering /etc/dhcp/dhclient-exit-hooks.d, dumping variables.
reason='PREINIT'
interface='eth0'
--------------------------
Thu Feb 14 08:12:12 -02 2019: entering /etc/dhcp/dhclient-enter-hooks.d, dumping variables.
reason='REBOOT'
interface='eth0'
new_ip_address='192.168.15.11'
new_network_number='192.168.15.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.15.255'
new_routers='192.168.15.1'
new_domain_name_servers='192.168.15.11'
new_netbios_name_servers='192.168.15.1'
new_ntp_servers='200.160.7.193'
--------------------------
Thu Feb 14 08:12:12 -02 2019: entering /etc/dhcp/dhclient-exit-hooks.d, dumping variables.
reason='REBOOT'
interface='eth0'
new_ip_address='192.168.15.11'
new_network_number='192.168.15.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.15.255'
new_routers='192.168.15.1'
new_domain_name_servers='192.168.15.11'
new_netbios_name_servers='192.168.15.1'
new_ntp_servers='200.160.7.193'
--------------------------
```
4. After that, Debian scripts take care of changing the ntp server to the one provided
by the dhcp server.
**Expected behavior**
I believe that the dhclient shouldn't set variables that weren't requested in `dhclient.conf`
**Environment:**
- Raspiberry Pi 3B
- Debian GNU/Linux 10 (buster) AArch64
- isc-dhclient-4.4.1
**Additional Information**
I've seen that there has been a lot of discussion on the bugs I've pointed out above,
there is a comment about using `supersede`, but I think this shouldn't be the preferred
solution since many people don't even touch in configuration files.
Also, the BTS indicates the bug has been forwarded upstream already, but I didn't find it.
And since I'm facing this annoying problem every time my rpi3 reboots, I've decided to
fill this bug.
I'll also add my `dhclient.conf` and the scripts I've talked about bellow.
<details>
<summary>dhclient.conf</summary>
```
# Configuration file for /sbin/dhclient.
#
# This is a sample configuration file for dhclient. See dhclient.conf's
# man page for more information about the syntax of this file
# and a more comprehensive list of the parameters understood by
# dhclient.
#
# Normally, if the DHCP server provides reasonable information and does
# not leave anything out (like the domain name, for example), then
# few changes must be made to this file, if any.
#
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes;
#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;
#require subnet-mask, domain-name-servers;
#timeout 60;
#retry 60;
#reboot 10;
#select-timeout 5;
#initial-interval 2;
#script "/sbin/dhclient-script";
#media "-link0 -link1 -link2", "link0 link1";
#reject 192.33.137.209;
#alias {
# interface "eth0";
# fixed-address 192.5.5.213;
# option subnet-mask 255.255.255.255;
#}
#lease {
# interface "eth0";
# fixed-address 192.33.137.200;
# medium "link0 link1";
# option host-name "andare.swiftmedia.com";
# option subnet-mask 255.255.255.0;
# option broadcast-address 192.33.137.255;
# option routers 192.33.137.250;
# option domain-name-servers 127.0.0.1;
# renew 2 2000/1/12 00:00:01;
# rebind 2 2000/1/12 00:00:01;
# expire 2 2000/1/12 00:00:01;
#}
```
</details>
<details>
<summary>debug</summary>
```
#
# The purpose of this script is just to show the variables that are
# available to all the scripts in this directory. All these scripts are
# called from dhclient-script, which exports all the variables shown
# before. If you want to debug a problem with your DHCP setup you can
# enable this script and take a look at /tmp/dhclient-script.debug.
# To enable this script set the following variable to "yes"
RUN="yes"
if [ "$RUN" = "yes" ]; then
echo "$(date): entering ${1%/*}, dumping variables." \
>> /tmp/dhclient-script.debug
# loop over the 4 possible prefixes: (empty), cur_, new_, old_
for prefix in '' 'cur_' 'new_' 'old_'; do
# loop over the DHCP variables passed to dhclient-script
for basevar in reason interface medium alias_ip_address \
ip_address host_name network_number subnet_mask \
broadcast_address routers static_routes \
rfc3442_classless_static_routes \
domain_name domain_search domain_name_servers \
netbios_name_servers netbios_scope \
ntp_servers \
ip6_address ip6_prefix ip6_prefixlen \
dhcp6_domain_search dhcp6_name_servers ; do
var="${prefix}${basevar}"
eval "content=\$$var"
# show only variables with values set
if [ -n "${content}" ]; then
echo "$var='${content}'" >> /tmp/dhclient-script.debug
fi
done
done
echo '--------------------------' >> /tmp/dhclient-script.debug
fi
```
</details>
<details>
<summary>dhclient-exit-hooks.d/ntp</summary>
```
NTP_CONF=/etc/ntp.conf
NTP_DHCP_CONF=/run/ntp.conf.dhcp
ntp_server_restart() {
invoke-rc.d ntp try-restart
}
ntp_servers_setup_remove() {
if [ ! -e $NTP_DHCP_CONF ]; then
return
fi
rm -f $NTP_DHCP_CONF
ntp_server_restart
}
ntp_servers_setup_add() {
if [ -e $NTP_DHCP_CONF ] && [ "$new_ntp_servers" = "$old_ntp_servers" ]; then
return
fi
if [ -z "$new_ntp_servers" ]; then
ntp_servers_setup_remove
return
fi
tmp=$(mktemp "$NTP_DHCP_CONF.XXXXXX") || return
chmod --reference=$NTP_CONF $tmp
chown --reference=$NTP_CONF $tmp
(
echo "# This file was copied from $NTP_CONF with the server options changed"
echo "# to reflect the information sent by the DHCP server. Any changes made"
echo "# here will be lost at the next DHCP event. Edit $NTP_CONF instead."
echo
echo "# NTP server entries received from DHCP server"
for server in $new_ntp_servers; do
echo "server $server iburst"
done
echo
sed '/^[[:space:]]*\(server\|peer\|pool\)[[:space:]]/d' $NTP_CONF
) >>$tmp
mv $tmp $NTP_DHCP_CONF
ntp_server_restart
}
ntp_servers_setup() {
case $reason in
BOUND|RENEW|REBIND|REBOOT)
ntp_servers_setup_add
;;
EXPIRE|FAIL|RELEASE|STOP)
ntp_servers_setup_remove
;;
esac
}
ntp_servers_setup
```
</details>Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/202Enhance dhclient to parse multiple instances in Option 17/43/1252022-03-09T19:00:29Zdongyang wangEnhance dhclient to parse multiple instances in Option 17/43/125---
name: Feature request
about: Enhance dhclient to parse multiple instances in Option 17/43/125
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure...---
name: Feature request
about: Enhance dhclient to parse multiple instances in Option 17/43/125
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration?
This is for DHCP client, and KEA doesn't support client.
- Are you sure what you would like to do is not possible using some other mechanisms?
Not sure, maybe there also has other way.
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
Sorry, I commit to here first. Upload the patch as an attachment.
[0001-Enhance-dhclient-to-parse-multiple-instances-in-Opti.patch](/uploads/0daaff86a3432d950fb316177a0666fb/0001-Enhance-dhclient-to-parse-multiple-instances-in-Opti.patch)
**Is your feature request related to a problem? Please describe.**
When DHCP server sends a single instance in Option 17/43/125 from the dhclient-exit-hooks,
dhclient can parse it well.
But if DHCP server sends multiple instances, dhclient only can parse the first one.
**Describe the solution you'd like**
Use a do-while to parse each "struct option_cache-->option" in the oclist.
**Describe alternatives you've considered**
**Additional context**
**Funding its development**
**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! It's my pleasure, I'm very glad to do these.
**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.
Maybe here has a typo: >>we may send you a message on **github **with questions when we have them.
We are on GitLab now :)
Using GitLab can contact me, thanks.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/178[dhclient] Client did not bind to the address even after receiving DHCPACK2022-03-09T18:59:26ZVivek Reddy[dhclient] Client did not bind to the address even after receiving DHCPACK**Describe the bug**
Usually, every DHCPACK message is followed by a bound log message.
```
Mar 29 10:20:46.328836 sonic INFO dhclient[3350]: DHCPREQUEST for 10.210.24.228 on eth0 to 255.255.255.255 port 67
Mar 29 10:20:46.329931 sonic...**Describe the bug**
Usually, every DHCPACK message is followed by a bound log message.
```
Mar 29 10:20:46.328836 sonic INFO dhclient[3350]: DHCPREQUEST for 10.210.24.228 on eth0 to 255.255.255.255 port 67
Mar 29 10:20:46.329931 sonic INFO dhclient[3350]: DHCPACK of 10.210.24.228 from 10.211.0.124
Mar 29 10:20:46.584251 sonic INFO dhclient[3350]: bound to 10.210.24.228 -- renewal in 1536 seconds.
Mar 29 10:21:19.521847 sonic INFO dhclient[7991]: DHCPRELEASE of 10.210.24.228 on eth0 to 10.211.0.124 port 67
```
DHCPRELEASE because there were systemd restarts in between and it made the dhclient to explicitly release the IP Address.
After a few such cycles and following the last DHCPACK, there was no bound to log message and the connection to the device was lost (no lease was generated as expected in the host file). We manually had to run `dhclient eth0` to get the IP Addr back.
```
Mar 29 10:25:54.446311 r-anaconda-70 INFO dhclient[3544]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
Mar 29 10:25:54.447348 r-anaconda-70 INFO dhclient[3544]: DHCPOFFER of 10.210.24.228 from 10.211.0.124
Mar 29 10:25:54.447477 r-anaconda-70 INFO dhclient[3544]: DHCPREQUEST for 10.210.24.228 on eth0 to 255.255.255.255 port 67
Mar 29 10:25:54.448561 r-anaconda-70 INFO dhclient[3544]: DHCPACK of 10.210.24.228 from 10.211.0.124
...
Mar 29 17:29:53.334129 r-anaconda-70 INFO dhclient[3544]: bound to 10.210.24.228 -- renewal in -23800 seconds.
```
The process though is surprisingly not dead, and it threw this bound to message after we manually ran 'dhclient eth0'. (Looked like it kinda stuck in a loop/deadlock)
The -23800 seconds signifies that the dhclient reached that point way after the lease has expired.
Ref: https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/dhclient.c#L1616
```
log_info("bound to %s -- renewal in %ld seconds.",
piaddr(client->active->address),
(long)(client->active->renewal - cur_time));
```
We suspected Dhclient Script Failure could be a reason. (https://gitlab.isc.org/isc-projects/dhcp/-/commit/845c85226e30173982f541fc60bd95747deabbe0) but not entirely sure of it.
This is hard to reproduce but happens every now and then.
Any inputs on why such behavior could arise and any suggestions on how to avoid it are appreciated.
**Environment:**
Version: isc-dhclient-4.4.1 (Not Compiled from source)
**dhclient.conf**
```
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option snmp-community code 224 = text;
option minigraph-url code 225 = text;
option acl-url code 226 = text;
option tftp-server-name code 66 = text;
option bootfile-name code 67 = text;
option user-class code 77 = text;
option provisioning-script-url code 239 = text;
option dhcp6.user-class code 15 = text;
option dhcp6.provisioning-script-url code 239 = text;
option dhcp6.boot-file-url code 59 = text;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, interface-mtu, dhcp6.fqdn,
rfc3442-classless-static-routes, ntp-servers, log-servers,snmp-community, minigraph-url, acl-url;
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/174Overwriting resolv.conf fails when resolv.conf is a bind mount with dhclient.2022-03-09T18:58:52ZPatrick NorthonOverwriting resolv.conf fails when resolv.conf is a bind mount with dhclient.- ISC DHCP version: 4.4.2
- Tested OS: Arch Linux, Fedora
`resolv.conf` become a bind mount typically inside a network namespace, if a file `/etc/netns/<namespace>/resolv.conf` is present. Running dhclient inside the namespace, it will ...- ISC DHCP version: 4.4.2
- Tested OS: Arch Linux, Fedora
`resolv.conf` become a bind mount typically inside a network namespace, if a file `/etc/netns/<namespace>/resolv.conf` is present. Running dhclient inside the namespace, it will fail to overwrite `resolv.conf`, with error `mv: cannot move '/etc/resolv.conf.dhclient-new' to '/etc/resolv.conf': Device or resource busy`.
Simple fix: Use `cat $new_resolv_conf > /etc/resolv.conf` instead of using `mv` in `client/scripts/linux`.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/161Sending old_ variables in BOUND callout2022-03-09T18:57:54Zcyrilbur-adderSending old_ variables in BOUND callout---
name: Sending old_ variables in BOUND callout
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or s...---
name: Sending old_ variables in BOUND callout
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org. If you really need to report it here, please set the confidential
field to true.
I have a patch on github please see here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
If you would be so kind as to allow me to post it here in your gitlab as per https://github.com/isc-projects/dhcp/blob/31e68e5e3b863a4859562e0bb808888d74af7497/CONTRIBUTING.md
**To Reproduce**
Everything is outlined in the commit message of the patch here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
**Expected behavior**
Everything is outlined in the commit message of the patch here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
**Environment:**
Not really relevant since I have a patch
**Additional Information**
None
**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?
NA
- Are you sure what you would like to do is not possible using some other mechanisms?
No
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
I've emailed the patch to dhcp-workers, no response
**Is your feature request related to a problem? Please describe.**
It is a patch to a likely bug
**Describe the solution you'd like**
Merge the patch
**Describe alternatives you've considered**
None
**Additional context**
None
**Funding its development**
I'm trying to provide you with a patch
**Participating in development**
I'm trying to provide you with a patch
**Contacting you**
Please contact me here or on github.https://gitlab.isc.org/isc-projects/dhcp/-/issues/118Failed to start the dhclient2022-03-09T18:56:26ZgaoxingwangFailed to start the dhclientThe dhclient can not start when the pid in dhclient-eth0.pid file is holding by another process which is not a dhclient.
The process name corresponding to the PID is not checked.
I think we should check process name before using dhclien...The dhclient can not start when the pid in dhclient-eth0.pid file is holding by another process which is not a dhclient.
The process name corresponding to the PID is not checked.
I think we should check process name before using dhclient -r to kill the process whose pid is saved in /var/run/dhclient-eth0.pidOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/220If DHCPv6 server is not responding, some times dhcp client process terminates...2022-03-09T18:55:11ZRamesh BendigeriIf DHCPv6 server is not responding, some times dhcp client process terminates with an error 'impossible condition reached'If the DHCPv6 server is not responding, some of times dhcp client process terminates with an error 'impossible condition reached' and results in not releasing/clearing previously acquired DHCP IP address and other DHCP attributes.
This ...If the DHCPv6 server is not responding, some of times dhcp client process terminates with an error 'impossible condition reached' and results in not releasing/clearing previously acquired DHCP IP address and other DHCP attributes.
This issue is seen only when the Dhcp server is not available and Dhcp ip address’s lease is expired at the Dhcp client side.
Some times dhclientv6 process stops with an error “Impossible condition at dhc6.c:318” during rebind time (when rebind interval is reaching zero) and results in not generating Dhcp release event.
This is an issue with ISC DHCP package of IPv6 dhcp client module.
What is expected : Dhcp client should not get terminated during rebind6 event if DHCPv6 server is not available.
Instead dhcp client should **release the ip address** and start with solicit messageOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/93dhclient -6 binds unadvertised address2022-03-09T18:51:22Zjvfranklindhclient -6 binds unadvertised address---
name: Dhclient -6 binds unadvertised address
about: If solicited and advertised addresses aren't the same, dhclient binds both
---
**Describe the bug**
After dhclient -6 releases a leased address, and restarts, it sends a Solicit r...---
name: Dhclient -6 binds unadvertised address
about: If solicited and advertised addresses aren't the same, dhclient binds both
---
**Describe the bug**
After dhclient -6 releases a leased address, and restarts, it sends a Solicit requesting that address again. If the DHCP server decides the client needs a different address (like if the system has switched to a different network, or the address was leased to another client), and includes the different address in the Advertise, dhclient winds up calling dhclient-script BOUND6 for both the old address and the new one. Both addresses get added to the interface.
**To Reproduce**
Steps to reproduce the behavior:
1. Start dhclient -6 with empty dhclient6.leases file. See that it gets an address (AddressA) and configures it to the interface.
2. Run dhclient -6 -r to release it.
3. Either switch the interface to a different network, or change the DHCPv6 server so it will be forced to hand out a different address (AddressB) the next time dhclient runs.
4. Start dhclient -6 again. A packet capture will show the Solicit requesting AddressA.
5. DHCPv6 server responds with Advertise containing AddressB.
6. Client and server complete the transaction with the Request/Reply for AddressB.
7. dhclient-script BOUND6 action will be called twice. First for AddressA, then for AddressB.
**Expected behavior**
AddressA should not be used, since it was not advertised to the client in Step 5 above. The host might no longer be on the network segment where that address is reachable, or the address could already be in use by another host, causing an address conflict.
**Environment:**
- ISC DHCP version: Behavior observed on both isc-dhclient-4.4.1 and isc-dhclient-4.4.2
- OS: CentOS 8.1, Dell iDRAC embedded Linux
- Which features were compiled in:
ISC DHCP source configure results:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Package:
Name: DHCP
Version: 4.4.2
C Compiler: gcc
Flags:
DEFS: -DHAVE_CONFIG_H
CFLAGS: -g -O2 -Wall -Werror -fno-strict-aliasing -I$(top_srcdir)/includes -I/home/user/dhcp-4.4.2/bind/include
DHCP versions: DHCPv4 and DHCPv6
Features:
debug: no
failover: yes
execute: yes
binary-leases: no
dhcpv6: yes
delayed-ack: yes
dhcpv4o6: no
relay-port: no
Developer:
ATF unittests : no
**Additional Information**
[dhclient6.pcap](/uploads/82938f52eef5b382f68333fc81bee040/dhclient6.pcap)
[dhclient6.log](/uploads/e08f84161367366eb905e18a068dce45/dhclient6.log)
**Describe the solution you'd like**
Dhclient should only configure the address that was advertised and requested with the DHCPv6 server.
**Participating in development**
Are you willing to participate in the feature development? Yes
Are you willing to take part in the design discussions? Yes
Are you willing to test an unreleased engineering code? Yes
**Contacting you**
jvfranklin@gmail.com or github account jvfranklinOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/142Overflow in lease time and potentially in renew/rebind of IPv6 client2022-03-07T13:16:09ZChristos ChryssochoidisOverflow in lease time and potentially in renew/rebind of IPv6 client---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6...---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6.c` cause overflow in systems using a **32 bit signed integer for the TIME data type**. As a result dhclient enters an infinite loop since a negative relative expiration time is considered immediately expired.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcp server IPv6 with a config containing the following:
```
default-lease-time 4294967294; # or -2
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
```
2. A client solicits a new lease by broadcasting a SOLICIT packet. The above server sends then an ADVERTISE, following by the client sending a REQUEST, and finally the server sending a REPLY.
3. The client then immediately repeats sending a SOLICIT packet.
4. This cycle goes on forever.
**Expected behavior**
After receiving the REPLY packet the client should not repeat sending a SOLICIT packet.
**Environment:**
isc-dhclient-4.1-ESV-R16
- OS: Embedded Linux (**MIPS64n32** architecture)
**Additional Information**
An example config for IPv6 dhcp server is the following:
[dhcpd6-example.conf](/uploads/556d0909d055e86398985aa5abc5ef74/dhcpd6-example.conf)
In the logs I'm seeing the following line:
> PRC: Renewal event scheduled in 3600 seconds, to run for 3600 seconds. PRC: Depreference scheduled in 7200 seconds. PRC: Expiration scheduled in **-2 seconds.**
**Some initial questions**
> - Are you sure your feature is not already implemented in the latest ISC DHCP version?
I've tested it with the latest ESV version of dhclient.
> - Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
It's a client issue, therefore migrating to Kea doesn't seem to provide solution to this problem.
> - Are you sure what you would like to do is not possible using some other mechanisms?
No.
> - Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
No.
**Describe the solution you'd like**
I'm attaching a patch that seems to solve this issue:[dhclient.patch](/uploads/d13a046a05524006b6571e003a35e327/dhclient.patch)
**Context**
Seems to happen when the TIME data type used for lifetime and renew/rebind time calculations is a 32 bit signed integer type.
**Participating in development**
Yes, I am willing to participate in the development.
**Contacting you**
contact email: christos.chryssochoidis@nokia.comOutstandinghttps://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? NOOutstanding