dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-03-09T19:00:02Zhttps://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/193DHCP Relay: replay from server is not forwarded (discarded ?)2022-03-09T19:13:59ZOlegDHCP Relay: replay from server is not forwarded (discarded ?)Hello, I have simple configuration of client-relay-server (by ISC):
1. client - 1 iface in net1 (10.0.0.0/24)
2. relay - 1 iface on net1 and 1 iface on net2 (10.0.10.0/24)
3. server - 1 iface on net2 (10.0.10.0/24).
When running...Hello, I have simple configuration of client-relay-server (by ISC):
1. client - 1 iface in net1 (10.0.0.0/24)
2. relay - 1 iface on net1 and 1 iface on net2 (10.0.10.0/24)
3. server - 1 iface on net2 (10.0.10.0/24).
When running it on **Linux Kernel 4.x.y **: all okey, request and replay are forwarded to/from server and IP address have been assigned to client.
When running on **Linux kernel 5.4.117 **: replay from server is lost somewhere in relay host or relay do not see it.
**Information about Relay**
My command line to run relay: _/usr/sbin/dhcrelay -d -pf /var/run/dhcrelay.pid -id eth3 -iu eth4 -c 10 -a 10.0.10.254_
Ip address of eth3 (to client) of relay is 10.0.0.1/24 and eth4 (to server) of relay is 10.0.10.1/24
**Information about Server**
Ip address of eth0 of server is 10.0.10.254/24
My command line to run dhcp server:_ /usr/sbin/dhcpd -user dhcpd -group dhcpd -cf /etc/dhcpd.conf eth0_
My config of dhcp server concerning to networks and ranges:
```
shared-network net-eth0 {
subnet 10.0.10.0 netmask 255.255.255.0 {
}
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.20;
}
}
```
I've used **tcpdump** on relay iface that looks to server and here is log:
1) Here is Request: 10.0.10.1 - is relay net2 iface of relay, 10.0.10.254 - is server net2 iface of server
`15:23:24.224319 08:00:27:eb:f2:44 > 08:00:27:2e:19:cd, ethertype IPv4 (0x0800), length 371: 10.0.10.1.67 > 10.0.10.254.67: BOOTP/DHCP, Request from 08:00:27:ef:1a:e9, length 329`
2) Here is Reply: 10.0.0.1 - is net1 iface of relay
`15:23:24.224778 08:00:27:2e:19:cd > 08:00:27:eb:f2:44, ethertype IPv4 (0x0800), length 342: 10.0.10.254.67 > 10.0.0.1.67: BOOTP/DHCP, Reply, length 300`
I've debugged also relay, and found, that when Replay needs to be received it was read be falback_discard() routine and relay can not see it. Here is debug of relay with some of my own debug-strings (comments starts with //):
```
//Initialization of relay staff
......
IPv4: Sending on Socket/fallback
//Here is omapi_iscsock_cb() called to read request
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
//before calling reader()
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343cc5e90 //address of reader (function got_one() )
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
IPv4: omapi_iscsock_cb: af reader(): status=0 --status of reading Request
//Here is when and where replay should be read but it is discarded
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
//before calling reader()
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343ce6a70 //address of reader (function fallback_discard() )
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343ce6a70 //address of reader (function fallback_discard() )
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
//Here is 2nd Request try
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343cc5e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
```
**For comparison with GOOD case**: this is log of relay:
```
IPv4: Sending on Socket/fallback
IPv4: disc_ifaces: in fallback_iface: setting fcntl
//Getting Request
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebb9e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebdaab0
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
**//Here is REPLAY**
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebb9e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=300
IPv4: do_relay4
IPv4: Forwarded BOOTREPLY for 08:00:27:ef:1a:e9 to 255.255.255.255
```
Tcpdump for good case:
```
//here is dump of eth4(to server) iface
18:17:39.866071 08:00:27:eb:f2:44 > 08:00:27:2e:19:cd, ethertype IPv4 (0x0800), length 371: 10.0.10.1.67 > 10.0.10.254.67: BOOTP/DHCP, Request from 08:00:27:ef:1a:e9, length 329
18:17:40.867748 08:00:27:2e:19:cd > 08:00:27:eb:f2:44, ethertype IPv4 (0x0800), length 342: 10.0.10.254.67 > 10.0.0.1.67: BOOTP/DHCP, Reply, length 300
//here is dump of eth3(to client) iface: this is what absent above in bad case: replay seen on net1 (eth3) iface of relay
18:19:04.575007 08:00:27:8f:96:7d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.0.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
```
Thanks!Outstandinghttps://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/184[PATCH] relay: fix IPv6 multicast address in documentation2022-03-09T19:11:59ZFoster Snowhill[PATCH] relay: fix IPv6 multicast address in documentation```diff
From e6ca44a168b5ae07cb2b6d7aa9c7548eaf82b7ff Mon Sep 17 00:00:00 2001
From: Foster Snowhill <2516-forst@users.noreply.gitlab.isc.org>
Date: Sun, 25 Apr 2021 15:23:16 +0200
Subject: [PATCH] relay: fix IPv6 multicast address in do...```diff
From e6ca44a168b5ae07cb2b6d7aa9c7548eaf82b7ff Mon Sep 17 00:00:00 2001
From: Foster Snowhill <2516-forst@users.noreply.gitlab.isc.org>
Date: Sun, 25 Apr 2021 15:23:16 +0200
Subject: [PATCH] relay: fix IPv6 multicast address in documentation
In the dhcrelay source code, parse_upstream() function by default defines the
destination address to be the All_DHCP_Servers multicast group (ff05::1:3).
However, the documentation says that it uses All_DHCP_Relay_Agents_and_Servers
(ff02::1:2). This is inconsisent with the implementation.
This commit fixes the documentation to also specify All_DHCP_Servers as the
default multicast group.
---
relay/dhcrelay.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/relay/dhcrelay.8 b/relay/dhcrelay.8
index 53cd28bf..10ebfe3d 100644
--- a/relay/dhcrelay.8
+++ b/relay/dhcrelay.8
@@ -325,7 +325,7 @@ forwarded. At least one \fB-u\fR option must be included in the command
line when running in DHCPv6 mode. The interface name \fIifname\fR is a
mandatory parameter. The destination unicast or multicast address can be
specified by \fIaddress%\fR; if not specified, the relay agent will forward
-to the DHCPv6 \fIAll_DHCP_Relay_Agents_and_Servers\fR multicast address.
+to the DHCPv6 \fIAll_DHCP_Servers\fR multicast address.
.PP
It is possible to specify the same interface with different addresses
more than once, and even, when the system supports it, to use the same
--
2.31.1
```
---
This patch is against `master` (commit 79110e525e0584d195327d31f4ee67e6a5e2fe7a).
For reference, the relevant line in `parse_upstream()` function: https://gitlab.isc.org/isc-projects/dhcp/-/blob/79110e525e0584d195327d31f4ee67e6a5e2fe7a/relay/dhcrelay.c#L1532
If possible, can I also please get a project allocation, so that in the future I can submit proper merge requests? Thanks!Outstandinghttps://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/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/175DHCP bug2022-01-13T11:46:10Zosullo23DHCP bug```
sudo /etc/init.d/isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since...```
sudo /etc/init.d/isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-03-22 05:02:56 PDT; 9min ago
Docs: man:dhcpd(8)
Process: 3086 ExecStart=/bin/sh -ec CONFIG_FILE=/etc/dhcp/dhcpd.conf; if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; fi; [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf $CONFIG_FILE $INTERFACES (code=exited, status=1/FAILURE)
Main PID: 3086 (code=exited, status=1/FAILURE)
Mar 22 05:02:56 ubuntu dhcpd[3086]:
Mar 22 05:02:56 ubuntu dhcpd[3086]: If you think you have received this message due to a bug rather
Mar 22 05:02:56 ubuntu dhcpd[3086]: than a configuration issue please read the section on submitting
Mar 22 05:02:56 ubuntu dhcpd[3086]: bugs on either our web page at www.isc.org or in the README file
Mar 22 05:02:56 ubuntu dhcpd[3086]: before submitting a bug. These pages explain the proper
Mar 22 05:02:56 ubuntu dhcpd[3086]: process and the information we find helpful for debugging.
Mar 22 05:02:56 ubuntu dhcpd[3086]:
Mar 22 05:02:56 ubuntu dhcpd[3086]: exiting.
Mar 22 05:02:56 ubuntu systemd[1]: isc-dhcp-server.service: Main process exited, code=exited, status=1/FAILURE
Mar 22 05:02:56 ubuntu systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
```
tomek: formatted for readability.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/170[ppc64el architecture only] Regresses when built against gcc-10 on ppc64el2022-01-13T11:34:56ZUtkarsh Gupta[ppc64el architecture only] Regresses when built against gcc-10 on ppc64elHello,
With https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/60 being merged, we (on Ubuntu) are getting a regression against network-manager on ppc64el architecture.
See logs [here](https://objectstorage.prodstack4-5.canonic...Hello,
With https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/60 being merged, we (on Ubuntu) are getting a regression against network-manager on ppc64el architecture.
See logs [here](https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/n/network-manager/20210305_165511_daa27@/log.gz).
As soon as I revert this patch and build with gcc-9, everything works fine again. But please note that this **only** happens on ppc64el architecture. Builds and tests on other architecture works fine, without any problems, really.
Is it known? If it isn't, can you perhaps take a look at this?
CC: @tmark^
Should you need any other information or anything, please let me know. I'll be also happy to test the patches (if you suggest any) on a ppc64el VM to fix this issue.
Thanks for your awesome work on this so far! :smile:Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/169dhcrelay doesn't set remote_port with `-p` option2022-03-09T19:06:28ZJonah Caplandhcrelay doesn't set remote_port with `-p` option---
name: dhcrelay doesn't set remote_port with `-p` option
about:
---
**Describe the bug**
Run a dhclient, dhcrelay, and dhcpd server using non standard ports. dhcrelay doesn't set the port on replies to the client.
**To Reproduce*...---
name: dhcrelay doesn't set remote_port with `-p` option
about:
---
**Describe the bug**
Run a dhclient, dhcrelay, and dhcpd server using non standard ports. dhcrelay doesn't set the port on replies to the client.
**To Reproduce**
Make sure target2->target1 is on a different subnet from target3->target1 so it doesn't get the reply from target3:
- Target1, running `dhcrelay -d -p 60 172.16.129.103`
- Target2, running `dhclient vmx1 -d -p 61`
- Target3, running `dhcpd -d -p 60 vmx0`
**Expected behavior**
dhcrelay relays the reply to dhclient on port 61, but the port on the outgoing BOOTREPLY is 0.
**Environment:**
**Additional Information**
suggested diff
```
if (!local_port) {
...
} else {
remote_port = htons(ntohs(local_port) + 1);
}
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/152Support DHCP relay on interfaces with zero MAC address2022-03-09T19:06:03ZQingtao CaoSupport DHCP relay on interfaces with zero MAC addressThe dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC a...The dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC address, the ipsecX interfaces built upon such wwanX interfaces won't have L2 addresses, resulting in the dhcrelay daemon unable to use them.
I will try to propose a patchset to support such interfaces.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/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/141dhcp-lease-list fails to parse /var/lib/dhcpd.leases when db-time-format is s...2020-12-03T15:38:00ZGregMoreldhcp-lease-list fails to parse /var/lib/dhcpd.leases when db-time-format is set to locale---
name: Bug Report
about: dhcp-lease-list script fails to parse leases file if db-time-format is set to locale
---
**Describe the bug**
`dhcp-lease-list` script fails to parse `/var/lib/dhcpd.leases` file if `db-time-format` is set ...---
name: Bug Report
about: dhcp-lease-list script fails to parse leases file if db-time-format is set to locale
---
**Describe the bug**
`dhcp-lease-list` script fails to parse `/var/lib/dhcpd.leases` file if `db-time-format` is set to `locale`
**To Reproduce**
1. In `dhcpd.conf`, set `db-time-format locale`
2. Restart dhcp service
3. On a dhcp client, run `dhclient -r`
4. On the server, run `dhcp-lease-list`: the lease does not appear
**Expected behavior**
Leases should appear in `dhcp-lease-list` command's output, even if `db-time-format` is set to `locale`
**Environment**
- ISC DHCP version: 4.4.1
- OS: Ubuntu Server 20.04 x64
**Additional Information**
After investigation, the problem occurs because of the following part in `dhcp-lease-list` Perl script:
```Perl
# skip invalid lines
next if not ($lease =~ /^\s+([\.\d]+)\s+{.*starts \d+ ([\/\d\ \:]+);.*ends \d+ ([\/\d\ \:]+);.*ethernet ([a-f0-9:]+);(.*client-hostname \"(\S+)\";)*/s);
```
Indeed, this regex does not match leases written with date format that respect the `db-time-format locale` flag, that is (according to `man dhcpd.leases`):
> If the db-time-format was configured to local, then the date fields appear as follows:\
`epoch <seconds-since-epoch>; # <day-name> <month-name> <day-number> <hours>:<minutes>:<seconds> <year>`Outstandinghttps://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/133can't update object: permission denied2022-01-13T11:24:53ZRamesh Sahoocan't update object: permission deniedTrying to delete a lease from the DHCP server with the following procedure and ending up with the following message.
can't update object: permission denied
```
# omshell
> connect
obj: <null>
> new lease
obj: lease
> set ip-address =...Trying to delete a lease from the DHCP server with the following procedure and ending up with the following message.
can't update object: permission denied
```
# omshell
> connect
obj: <null>
> new lease
obj: lease
> set ip-address = 192.168.6.20
obj: lease
ip-address = c0:a8:06:14
> open
obj: lease
ip-address = c0:a8:06:14
state = 00:00:00:02
client-hostname = "rhel7-c1"
subnet = 00:00:00:02
pool = 00:00:00:03
hardware-address = 08:00:27:a5:22:0a
hardware-type = 00:00:00:01
ends = 5f:4d:8a:81
starts = 5f:4d:1a:01
tstp = 00:00:00:00
tsfp = 00:00:00:00
atsfp = 00:00:00:00
cltt = 5f:4d:1a:01
flags = 00
> unset ip-address
obj: lease
ip-address = <null>
state = 00:00:00:02
client-hostname = "rhel7-c1"
subnet = 00:00:00:02
pool = 00:00:00:03
hardware-address = 08:00:27:a5:22:0a
hardware-type = 00:00:00:01
ends = 5f:4d:8a:81
starts = 5f:4d:1a:01
tstp = 00:00:00:00
tsfp = 00:00:00:00
atsfp = 00:00:00:00
cltt = 5f:4d:1a:01
flags = 00
> update
can't update object: permission denied
obj: lease
ip-address = <null>
state = 00:00:00:02
client-hostname = "rhel7-c1"
subnet = 00:00:00:02
pool = 00:00:00:03
hardware-address = 08:00:27:a5:22:0a
hardware-type = 00:00:00:01
ends = 5f:4d:8a:81
starts = 5f:4d:1a:01
tstp = 00:00:00:00
tsfp = 00:00:00:00
atsfp = 00:00:00:00
cltt = 5f:4d:1a:01
flags = 00
```
```
# dhcpd --version
isc-dhcpd-4.2.5
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/126Subnet mask improperly validated2022-03-09T18:57:18ZDiego Garcia del RioSubnet mask improperly validated---
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**
Subnet masks are not completely validated for proper formatting. Thus the system accepts an IP address such as 10.254.130.65 as a subnet mask in certain cases. This causes several issues as hosts from the "wrong" subnet will be percieved to belong to this subnet and overall wreak havoc in the network
**To Reproduce**
Steps to reproduce the behavior:
create the following subnet:
```
subnet 10.254.130.64 netmask 10.254.130.65 {
option subnet-mask 10.254.130.65;
option domain-name-servers 135.227.24.250, 152.148.152.45, 152.148.152.38;
option interface-mtu 1600;
}
```
and then this host:
```
host CLIENT1 { hardware ethernet AA:00:CC:11:EE:22; fixed-address 10.254.170.192; }
```
Starting dhcpd will not complain at all. Accepting the configuration.
When client1 sends a DHCP discover, it will be offered the 10.254.170.192 address but the subnet mask of 10.254.130.65
![dhcp_wron_mask](/uploads/5a9aae012a6c019e5769048840b3758c/dhcp_wron_mask.png)
shows the subnet mask being sent to the client
My config is quite scaled (but I can provide the complete config file if needed).
So there are two issues:
- Invalid subnet masks are accepted
- These invalid subnet masks create issues where hosts are mapped to the wrong subnet and get options from those subnets
**Expected behavior**
- Subnet masks should be validated to be "contiguous ones" when seen in binary
- host-to-subnet validation seems to have to be revisited
**Environment:**
- ISC DHCP version: which release? if it's compiled from git, which revision. Use `dhcpd --version`
to find out.
```
[root@wfnupxe1 ~]# dhcpd --version
isc-dhcpd-4.2.5
```
```
[root@wfnupxe1 ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
```
Installed from RPM
**Additional Information**
I can provide the config files separately but due to the size, its difficult to anonymise.. Also, they are quite large but I think this small sample should be enough to reproduce.
I have not checked the code for the DHCP client to see if it accepts the non-standard mask, but at least both the intel PXE dhcp agent as well as the ATEN IPMI DHCP seem to have accepted the subnet mask and thus result in broken connectivity.
**Additional context**
Add any other context about the feature request here.
**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.
contact me at garci66@gmail.com or diego.garcia_del_rio@nokia.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/120Unable to get MAC in the DHCPv6 leases database while MAC address is availabl...2020-08-12T14:34:40ZGaneshUnable to get MAC in the DHCPv6 leases database while MAC address is available in the DHCPv6 client request packet.---
name: Get DHCPv6 MAC Address of client in dhcpd6.leases database.
about: Need a way to print DHCPv6 MAC address in the dhcpd6.leases.
---
**Describe the bug**
I have captured a DHCPv6 IP request packet. In that packet, I am getting...---
name: Get DHCPv6 MAC Address of client in dhcpd6.leases database.
about: Need a way to print DHCPv6 MAC address in the dhcpd6.leases.
---
**Describe the bug**
I have captured a DHCPv6 IP request packet. In that packet, I am getting Link-Layer Address(MAC) as a parameter under the DHCPv6-Client Identifier section. I want that MAC address should print in the dhcpv6 leases database file /var/lib/dhcpd6.leases. Let me know is there any way to print DHCPv6 request options in the leases database.
**Expected behavior**
If DHCPv6 request packet is getting any specific options like MAC address then there should be configuration to print that data in the dhcpd6.leases database.
**Environment:**
- ISC DHCP version: 4.4.2
- OS: CentOS7Outstandinghttps://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/1152038 problem2020-07-30T07:29:58Zgaoxingwang2038 problemThe 2038 problem does not bother 64Bit architecture, maybe we should add a judgment,like this :
```
if (year >= 138 && sizeof(TIME) < 8)
return(MAX_TIME);
```The 2038 problem does not bother 64Bit architecture, maybe we should add a judgment,like this :
```
if (year >= 138 && sizeof(TIME) < 8)
return(MAX_TIME);
```Outstanding