dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2024-01-09T02:44:49Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/1020The dhclient cannot parse the IAID successfully,when it is written as string ...2024-01-09T02:44:49ZMingshuai Renrenmingshuai@huawei.comThe dhclient cannot parse the IAID successfully,when it is written as string which contains '"' characterAs we all know, the IAID values in lease is written as quoted strings with the default format.
Generally, the dhclient can successfully parse the IAID value from the IAID string in the lease, but fails to parse the IAID value from the IA...As we all know, the IAID values in lease is written as quoted strings with the default format.
Generally, the dhclient can successfully parse the IAID value from the IAID string in the lease, but fails to parse the IAID value from the IAID string which contains '"'.
The reason is that when the dhclient parses the IAID character string, the character '“' is used as the end of the string.
Modifying the condition for writing the IAID value as a string rather than modifying the code for parsing leases is a better way to solve this problem.
```
diff --git a/common/print.c b/common/print.c
index ebe985d..536e8b4 100644
--- a/common/print.c
+++ b/common/print.c
@@ -427,7 +427,7 @@ void print_hex_or_string (len, data, limit, buf)
return;
for (i = 0; (i < (limit - 3)) && (i < len); i++) {
- if (!isascii(data[i]) || !isprint(data[i])) {
+ if (!isascii(data[i]) || !isprint(data[i]) || (data[i] == '"')) {
print_hex_only(len, data, limit, buf);
return;
}
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/1018Unable to add forward map2023-11-23T03:54:46Zwolverin-aUnable to add forward mapHello
After upgrading the debian version from 8 to 10, isc-dhcp-server (4.4.1-2+deb10u3) stopped updating zones on the bind9 (1:9.10.3.dfsg.P4-12.3+deb9u12) server on Debian 9
There are such errors in the logs
```plaintext
Nov 22 15:0...Hello
After upgrading the debian version from 8 to 10, isc-dhcp-server (4.4.1-2+deb10u3) stopped updating zones on the bind9 (1:9.10.3.dfsg.P4-12.3+deb9u12) server on Debian 9
There are such errors in the logs
```plaintext
Nov 22 15:00:12 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b059300
Nov 22 15:00:30 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b059a20
Nov 22 15:00:30 server dhcpd[]: Unable to add forward map from secretar.xxxxxx.ru to 192.168.yy.xxx: operation canceled
Nov 22 15:01:03 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b058540
Nov 22 15:01:03 server dhcpd[]: Can't remove reverse map on xxx.yy.168.192.in-addr.arpa.: operation canceled
Nov 22 15:02:23 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b059300
Nov 22 15:02:23 server dhcpd[]: Can't remove reverse map on xxx.yy.168.192.in-addr.arpa.: operation canceled
```
nsupdate like **nsupdate -k dhcpd.key** is work
my config
```
# grep -v ^# dhcpd.conf
ddns-update-style standard;
ddns-updates on;
ddns-domainname "domainame.ru";
do-forward-updates on;
update-static-leases on;
update-conflict-detection true;
include "/etc/dhcp/dhcpd.key";
zone domainname.ru {
primary 192.168.yy.2;
key dhcpd-key;
}
zone yy.168.192.in-addr.arpa {
primary 192.168.yy.2;
key dhcpd-key;
}
option domain-name "domainname.ru";
option domain-name-servers 192.168.yy.2;
option local-pac-server code 252 = text;
option local-pac-server "http://proxy/proxy.pac\000";
default-lease-time 36000; # 10h
max-lease-time 86400; # 24h
authoritative;
log-facility local7;
shared-network networkname {
subnet 192.168.yy.0 netmask 255.255.255.0 {
range 192.168.yy.10 192.168.yy.250;
option broadcast-address 192.168.yy.255;
option routers 192.168.yy.2;
option ntp-servers 192.168.yy.2;
filename "pxelinux.0";
next-server 192.168.yy.1;
}
}
host hostname {
hardware ethernet 00:11:0a:f8:xx:xx;
fixed-address 192.168.yy.xxx;
}
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/1017KEAME leases python script2023-10-22T14:47:28Zvladimir9876KEAME leases python script---
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**
dhcp2kea.py doesn't support ISC DHCP HA leases
**To Reproduce**
Steps to reproduce the behavior:
1. # python3 dhcp2kea.py /var/lib/dhcpd/dhcpd.leases
Traceback (most recent call last):
File "dhcp2kea.py", line 329, in <module>
print(leases,file=f) # writing
File "dhcp2kea.py", line 98, in __str__
max_life = (self.ver==4) and (v["ends"]-v["starts"]) or v["max-life"]
KeyError: 'ends'
**Expected behavior**
A clear and concise description of what you expected to happen:
No errors reported.
**Environment:**
- ISC DHCP version: 4.2.5
- OS: CentOS 7
**Additional Information**
Add any other context about the problem here. In particular, feel free to share your config file and
logs from around the time error occurred. Don't be shy to send more logs than you think are
relevant. It is easy to grep large log files. It is tricky to guess what may have happened without
any information.
Make sure you anonymize your config files (at the very lease make sure you obfuscate your database
credentials, but you may also replace your actual IP addresses and host names with example.com
and 10.0.0.0/8 or 2001:db8::/32).
**Some initial questions**
The script doesn't handle leases in the 'backup' state
**Is your feature request related to a problem? Please describe.**
KEAME leases migration tool is not working with DHCP HA leases
**Describe the solution you'd like**
# diff -u dhcp2kea.py dhcp2kea.py.ok
--- dhcp2kea.py 2023-10-22 07:42:53.735809274 -0700
+++ dhcp2kea.py.ok 2023-10-22 07:42:08.098860761 -0700
@@ -92,8 +92,8 @@
s = s4 if self.ver == 4 else s6
self.written = 0
for k,v in self.leases.items():
- if "binding state" in v and v["binding state"].startswith("free"): # ticket #4
- continue # skip free and backup leases
+ if "binding state" in v and (v["binding state"].startswith("free") or v["binding state"].startswith("backup")): # ticket #4
+ continue # skip free and backup leases
self.written += 1
max_life = (self.ver==4) and (v["ends"]-v["starts"]) or v["max-life"]
if "valid_lifetime" in v :
**Describe alternatives you've considered**
I just modified the line 95 in the script
**Additional context**
Add any other context about the feature request here.
**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?
**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?
**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.https://gitlab.isc.org/isc-projects/dhcp/-/issues/1015dhclient pid file is not getting deleted when process dies2023-11-14T08:38:26ZDivyadhclient pid file is not getting deleted when process diesI am observing that dhclient does not delete the pid file created by it when process exits.
Is this the expected behavior?
Should dhclient itself should have removed the pid file, or is the user expected to manually remove the pid file...I am observing that dhclient does not delete the pid file created by it when process exits.
Is this the expected behavior?
Should dhclient itself should have removed the pid file, or is the user expected to manually remove the pid file? Are there any documented guidelines on this?
```
# cat /var/run/myclient.pid
cat: /var/run/myclient.pid: No such file or directory
# dhclient -d -v eth2 -1 -pf /var/run/myclient.pid
Internet Systems Consortium DHCP Client 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth2/20:78:52:ff:5f:2e
Sending on LPF/eth2/20:78:52:ff:5f:2e
Sending on Socket/fallback
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 3 (xid=0x49fb9b59)
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 3 (xid=0x49fb9b59)
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 5 (xid=0x49fb9b59)
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 10 (xid=0x49fb9b59)
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 17 (xid=0x49fb9b59)
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 9 (xid=0x49fb9b59)
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 14 (xid=0x49fb9b59)
No DHCPOFFERS received.
Unable to obtain a lease on first try. Exiting.
# cat /var/run/myclient.pid
406186
#
```
If I understood the behavior correctly, on startup dhclient will check whether the pid mentioned in pid file is alive. If pid is alive,it exits with error `dhclient(<pid>) is already running - exiting.`.
What if the pids in Linux are recycled and reused for a different process?
i.e if `406186` in above example is later assigned to another process that stays alive, next invocation of dhclient will fail.
Another possibility is that if the path in which pid file is stored in persistent over system reboot, there is a high chance that `406186` gets assigned to another process that stays alive and invocation of dhclient will fail after system reset.
System details:
```
# dhclient --version
isc-dhclient-4.4.3-P1
OS: Linux
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/434Linux packet filter bug fixes and improvements2023-09-08T10:23:49ZMorten BrørupLinux packet filter bug fixes and improvementsPlease find a patch for the ISCP DHCP Server regarding the Linux packet filter below, which provides the following modifications:
1. Optimization: The BPF program order has been reorganized to reduce the filter processing workload in th...Please find a patch for the ISCP DHCP Server regarding the Linux packet filter below, which provides the following modifications:
1. Optimization: The BPF program order has been reorganized to reduce the filter processing workload in the kernel.
Furthermore, it is superfluous to BPF_LD the port twice in the relay filter, so the second BPF_LD has been removed.
2. Bugfix: The test for fragmented packets did not drop the first fragment.
3. Bugfix: Non-DHCP packets may be received on the socket in the period from the socket was created until the filter was attached to it. So drain the socket after the filter has been attached.
PS: I have previously contributed a similar patch to KEA.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
---
```
$ diff -u bpf.c.orig bpf.c
--- bpf.c.orig 2023-09-03 15:05:06.481202014 +0200
+++ bpf.c 2023-09-03 17:48:26.057021797 +0200
@@ -5,6 +5,7 @@
/*
* Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC")
* Copyright (c) 1996-2003 by Internet Software Consortium
+ * Copyright (C) 2023 SmartShare Systems
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
@@ -168,28 +169,31 @@
#if defined (USE_BPF_RECEIVE) || defined (USE_LPF_RECEIVE)
/* Packet filter program...
+ Most packets are not DHCP packets. By designing the filter to detect
+ non-DHCP packets as early as possible, we reduce the kernel's BPF
+ processing workload.
XXX Changes to the filter program may require changes to the constant
offsets used in if_register_send to patch the BPF program! XXX */
struct bpf_insn dhcp_bpf_filter [] = {
+ /* Get the IP header length... */
+ BPF_STMT (BPF_LDX + BPF_B + BPF_MSH, 14),
+
+ /* Make sure it's to the right port... */
+ BPF_STMT (BPF_LD + BPF_H + BPF_IND, 16),
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 7), /* patch */
+
/* Make sure this is an IP packet... */
BPF_STMT (BPF_LD + BPF_H + BPF_ABS, 12),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 8),
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 5),
/* Make sure it's a UDP packet... */
BPF_STMT (BPF_LD + BPF_B + BPF_ABS, 23),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 6),
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 3),
/* Make sure this isn't a fragment... */
- BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20),
- BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 4, 0),
-
- /* Get the IP header length... */
- BPF_STMT (BPF_LDX + BPF_B + BPF_MSH, 14),
-
- /* Make sure it's to the right port... */
- BPF_STMT (BPF_LD + BPF_H + BPF_IND, 16),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 1), /* patch */
+ BPF_STMT (BPF_LD + BPF_H + BPF_ABS, 20),
+ BPF_JUMP (BPF_JMP + BPF_JSET + BPF_K, 0x3fff, 1, 0),
/* If we passed all the tests, ask for the whole packet. */
BPF_STMT (BPF_RET + BPF_K, (u_int)-1),
@@ -203,28 +207,27 @@
* For relay port extension
*/
struct bpf_insn dhcp_bpf_relay_filter [] = {
- /* Make sure this is an IP packet... */
- BPF_STMT (BPF_LD + BPF_H + BPF_ABS, 12),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 10),
-
- /* Make sure it's a UDP packet... */
- BPF_STMT (BPF_LD + BPF_B + BPF_ABS, 23),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 8),
-
- /* Make sure this isn't a fragment... */
- BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20),
- BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 6, 0),
-
/* Get the IP header length... */
BPF_STMT (BPF_LDX + BPF_B + BPF_MSH, 14),
/* Make sure it's to the right port... */
BPF_STMT (BPF_LD + BPF_H + BPF_IND, 16),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 67, 2, 0), /* patch */
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 67, 1, 0), /* patch */
/* relay can have an alternative port... */
- BPF_STMT (BPF_LD + BPF_H + BPF_IND, 16),
- BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 1), /* patch */
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 7), /* patch */
+
+ /* Make sure this is an IP packet... */
+ BPF_STMT (BPF_LD + BPF_H + BPF_ABS, 12),
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 5),
+
+ /* Make sure it's a UDP packet... */
+ BPF_STMT (BPF_LD + BPF_B + BPF_ABS, 23),
+ BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 3),
+
+ /* Make sure this isn't a fragment... */
+ BPF_STMT (BPF_LD + BPF_H + BPF_ABS, 20),
+ BPF_JUMP (BPF_JMP + BPF_JSET + BPF_K, 0x3fff, 1, 0),
/* If we passed all the tests, ask for the whole packet. */
BPF_STMT (BPF_RET + BPF_K, (u_int)-1),
@@ -357,10 +360,11 @@
p.bf_len = dhcp_bpf_relay_filter_len;
p.bf_insns = dhcp_bpf_relay_filter;
- dhcp_bpf_relay_filter [10].k = ntohs (relay_port);
+ dhcp_bpf_relay_filter [2].k = ntohs (local_port);
+ dhcp_bpf_relay_filter [3].k = ntohs (relay_port);
}
#endif
- p.bf_insns [8].k = ntohs (local_port);
+ dhcp_bpf_filter [2].k = ntohs (local_port);
if (ioctl (info -> rfdesc, BIOCSETF, &p) < 0)
log_fatal ("Can't install packet filter program: %m");
$ diff -u lpf.c.orig lpf.c
--- lpf.c.orig 2023-09-03 15:50:27.305763266 +0200
+++ lpf.c 2023-09-03 17:16:42.999729478 +0200
@@ -6,6 +6,7 @@
/*
* Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC")
* Copyright (c) 1996-2003 by Internet Software Consortium
+ * Copyright (C) 2023 SmartShare Systems
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
@@ -249,6 +250,8 @@
static void lpf_gen_filter_setup (info)
struct interface_info *info;
{
+ unsigned char ibuf [1536];
+ int length;
struct sock_fprog p;
memset(&p, 0, sizeof(p));
@@ -270,10 +273,11 @@
p.len = dhcp_bpf_relay_filter_len;
p.filter = dhcp_bpf_relay_filter;
- dhcp_bpf_relay_filter [10].k = ntohs (relay_port);
+ dhcp_bpf_relay_filter [2].k = ntohs (local_port);
+ dhcp_bpf_relay_filter [3].k = ntohs (relay_port);
}
#endif
- dhcp_bpf_filter [8].k = ntohs (local_port);
+ dhcp_bpf_filter [2].k = ntohs (local_port);
if (setsockopt (info -> rfdesc, SOL_SOCKET, SO_ATTACH_FILTER, &p,
sizeof p) < 0) {
@@ -289,6 +293,13 @@
}
log_fatal ("Can't install packet filter program: %m");
}
+
+ /* Non-DHCP packets may have been received before the filter was
+ attached, so drain the socket. */
+ do {
+ length = recv (info -> rfdesc, ibuf, sizeof ibuf,
+ MSG_DONTWAIT | MSG_TRUNC);
+ } while (length > 0);
}
#if defined (HAVE_TR_SUPPORT)
```https://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/280format string report2023-04-20T08:11:52ZPeter Daviesformat string reportformat string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse...format string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse.c#L5611
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/keama/keama.c#L209
To reproduce these bugs on Ubuntu 22.04, you may follow these steps:
```
raptor@fnord:~$ cp /sbin/dhclient . # copy to local directory to bypass apparmor policy
raptor@fnord:~$ echo "include foo" > %n%n%n%n
raptor@fnord:~$ echo "include foo" > %x%x%x%x
raptor@fnord:~$ ./dhclient -cf %n%n%n%n # write to memory, caught by exploit mitigations
*** %n in writable segment detected ***
raptor@fnord:~$ ./dhclient -cf %x%x%x%x # read from memory, notice the leak in the syslog file
RTNETLINK answers: Operation not permitted
RTNETLINK answers: Operation not permitted
raptor@fnord:~$ grep "filename string expected" /var/log/syslog
Apr 7 19:28:01 fnord dhclient[5389]: 7cb92e0d7200 line 1: filename string expected.
```
I've just noticed ISC DHCP has recently reached EOL and I can't think of any scenario in which these bugs could be exploited in order to cross a security boundary. However, as format string bugs are a very powerful exploitation primitive, in my opinion they should be fixed in any case just to be careful.
Please let me know if you intend to issue a fix and/or request a CVE ID.
Regards,
--
Marco Ivaldihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/278isc dhcp missing check the length of server identifier2023-04-05T14:50:12ZPeter Daviesisc dhcp missing check the length of server identifier
Date: 21/03/2023, 08.50
Hello, I have find a bug in isc-dhcp 4.4.3. The length of server identifier option is 4 bytes. While, I find in dhcprequest() it dose not check the length of it before memecpy the data.
```
oc = l...
Date: 21/03/2023, 08.50
Hello, I have find a bug in isc-dhcp 4.4.3. The length of server identifier option is 4 bytes. While, I find in dhcprequest() it dose not check the length of it before memecpy the data.
```
oc = lookup_option (&dhcp_universe, packet -> options, DHO_DHCP_SERVER_IDENTIFIER);
memset (&data, 0, sizeof data);
if (oc &&
evaluate_option_cache (&data, packet, (struct lease *)0,
(struct client_state *)0,
packet -> options, (struct option_state *)0,
&global_scope, oc, MDL)) {
sip.len = 4;
memcpy (sip.iabuf, data.data, 4);
```
Thus, I construct a packet with server identifier option 2 bytes("\x02AA"). And I find that it will overread and show the buffer info in the log, as show in the figure: (see email)
Also, I have found that there also has missing length check of the following options. But I can not tirgger them by poc, so I think these may be a bug.
- options 50 dhcprequest() dhcp.c line 472
- option 59 ack_lease() dhcp.c line3368
- option 58 ack_lease() dhcp.c line3385
- option 118 ack_lease() dhcp.c line3302https://gitlab.isc.org/isc-projects/dhcp/-/issues/275Dhcp server is not starting when used with NetworkManager2022-12-11T22:28:46ZMichał StrugDhcp server is not starting when used with NetworkManager---
name: Dhcp server is not starting when used with NetworkManager
about: isc-dhcp-server and NetworkManager
---
**Describe the bug**
When using `isc-dhcp-server` with `NetworkManager` after rebooting the PC `isc-dhcp-server` service...---
name: Dhcp server is not starting when used with NetworkManager
about: isc-dhcp-server and NetworkManager
---
**Describe the bug**
When using `isc-dhcp-server` with `NetworkManager` after rebooting the PC `isc-dhcp-server` service fails to start with error message:
```
No subnet declaration for enp1s0 (no IPv4 addresses).
** Ignoring requests on enp1s0. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface enp1s0 is attached. **
Not configured to listen on any interfaces!
```
Dhcp server is configured properly, if I run `systemctl start isc-dhcp-server` it starts without issues.
**To Reproduce**
1. Install `NetworkManager` and configure it as default network management service for `systemctl`, use static IP configuration.
2. Install `isc-dhcp-server`
3. Configure `isc-dhcp-server` (`/etc/default/isc-dhcp-server`, `/etc/dhcp/dhcpd.conf`)
4. Ensure dhcp server works fine and assigns IP addresses
4. Reboot PC
**Expected behavior**
`isc-dhcp-server` service is tarted after PC boots up.
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Debian 11
**Additional Information**
Root cause of this issue is that the `isc-dhcp-server` is started before `NetowrkManager` assings IP to the network interface configured to use with dhcp server, regardless it is configured in `isc-dhcp-server.service` file to wait for `network-online.target`. This happends because `NetworkManager-wait-online.service` uses internally `nm-online` command witch only waits for starting service, not the connection.
I've found the solution for this issue in this topic: https://unix.stackexchange.com/a/560539
but it requires update of `NetworkManager-wait-online.service` (remove `-s` parameter from call to `nm-online`).
Workaround for that issue is to update `isc-dhcp-server.service` `[Service]` section with:
```
Restart=on-failure
RestartSec=5s
```
Another workaround would be to add some delay (2 sec) to startup script `/etc/init.d/isc-dhcp-server`.https://gitlab.isc.org/isc-projects/dhcp/-/issues/274dhcp-lease-list lease ordering2022-11-25T08:04:44ZMichael Nydeggerdhcp-lease-list lease orderingHi,
I believe that the output ordering of dhcp-lease-list.pl ensured by this code (line 137-141):
```perl
if ($opt_keep eq 'all') {
push(@leases, \%entry);
} elsif (not defined $tmp_leases{$mac} or $tmp_leases{$mac}{'date_end'} gt $d...Hi,
I believe that the output ordering of dhcp-lease-list.pl ensured by this code (line 137-141):
```perl
if ($opt_keep eq 'all') {
push(@leases, \%entry);
} elsif (not defined $tmp_leases{$mac} or $tmp_leases{$mac}{'date_end'} gt $date_end) {
$tmp_leases{$mac} = \%entry;
}
```
is the exact opposite of what is stated in the script help (it will print the oldest lease).
I propose changing the comparison to lt:
```perl
if ($opt_keep eq 'all') {
push(@leases, \%entry);
} elsif (not defined $tmp_leases{$mac} or $tmp_leases{$mac}{'date_end'} gt $date_end) {
$tmp_leases{$mac} = \%entry;
}
```
to print the latest lease.https://gitlab.isc.org/isc-projects/dhcp/-/issues/273Failure when using recorded lease causes all virtual interfaces to be flushed...2022-11-24T03:55:14ZChinmay PendharkarFailure when using recorded lease causes all virtual interfaces to be flushed on Linux---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
If a `dhclient` instance isn't able to connect to a DHCP server when it times out it tries to check if one of the previously recoded leases is stil...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
If a `dhclient` instance isn't able to connect to a DHCP server when it times out it tries to check if one of the previously recoded leases is still valid, and if so tries to use it. `dhclient-script` on Linux sets the IP address and Gateway from the lease and tries to `ping` the Gateway, when that fails it flushes ALL interfaces (including virtual interfaces) that may have been setup outside of `dhclient`.
**To Reproduce**
Steps to reproduce the behavior:
1. Run `dhclient` with the default config on a modern Debian/Ubuntu.
2. Configure the DHCP server on the network to give a longer lease (1hr). This makes it easier to test.
3. Ensure that `dhclient` gets the lease from the server. Check if the /var/lib/dhcp/dhclient.eth0.leases file exists.
4. Create virtual interface using `sudo ip addr add "192.168.42.1/16" brd + dev eth0 label eth0:1`
5. Verify that the virtual interface (eth0:1) is up using `ip addr`
6. Disconnect the connection to the DHCP server
7. Restart `dhclient`
8. Wait for `dhclient` to timeout (default 300s)
9. Check if the virtual interface (eth0:1) is up. It isn't.
**Expected behavior**
The virtual interface (eth0:1) should not be removed even if DHCP request fails.
**Environment:**
- ISC DHCP version:
- OS: Ubuntu
**Additional Information**
Looking at the [`dhclient-script` source for linux](https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux), in case of `TIMEOUT` and when pinging the recorded lease IP address fails, ALL IP addresses are flushed from the interface :
```
# flush all IPs from interface
ip -4 addr flush dev ${interface}
```
from https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L397
Changing L397 to `${ip} -4 addr flush dev ${interface} label ${interface}` should fix this.
I have tested this with a custom script file. And it seems to fix the issue.https://gitlab.isc.org/isc-projects/dhcp/-/issues/271Consider including bind unpacked sources2022-11-04T15:53:04ZSantiagoConsider including bind unpacked sourcesFor packaging purposes, I think it would be easier to have the included bind source unpacked, instead of a tar.
It would make it easier to e.g. update generated configuration files with `autoreconf` (c.f. #256)For packaging purposes, I think it would be easier to have the included bind source unpacked, instead of a tar.
It would make it easier to e.g. update generated configuration files with `autoreconf` (c.f. #256)https://gitlab.isc.org/isc-projects/dhcp/-/issues/270dhcrelay error2022-11-01T15:50:00ZmyNameBorisdhcrelay errorIf there are more than 3000 interfaces, then I get an error:
```
Unable to register fd with library out of range
Can't register I/O handle for vlan3051.101: out of range
```If there are more than 3000 interfaces, then I get an error:
```
Unable to register fd with library out of range
Can't register I/O handle for vlan3051.101: out of range
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/265dhcp server function doesn't work after interface status changes from DOWN to UP2022-10-10T07:17:51Zpoe luodhcp server function doesn't work after interface status changes from DOWN to UPafter configured /etc/default/isc-dhcp-server and /etc/dhcp/dhcpd.conf, i started isc-dhcp-server via systemctl restart isc-dhcp-server (interface is DOWN currently).
checking process status with systemctl status isc-dhcp-server, it sho...after configured /etc/default/isc-dhcp-server and /etc/dhcp/dhcpd.conf, i started isc-dhcp-server via systemctl restart isc-dhcp-server (interface is DOWN currently).
checking process status with systemctl status isc-dhcp-server, it showed like below:
No subnet declaration for eno6 (no IPv4 addresses).
** Ignoring requests on eno6. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface eno6 is attached. **
then i plugged in a cable into eno6, it turned to UP status, but dhcp server function seems not working, because the client didn't get any ip address.
however, if i plugged in a cable first, then start isc-dhcp-server, it worked well if i unplugged the cable and re-plugged back.
what i want to know is that can isc-dhcp-server auto detect the listed interfaces status, when interfaces turn to UP status, it will always assign ip address to client successfully without restarting process manually.
my env is Ubuntu 18.04.
thanks.https://gitlab.isc.org/isc-projects/dhcp/-/issues/264dhclient doesn't receive DHCP offers from kernel ("No DHCPOFFERS received")2022-09-23T22:30:55ZRoger Chendhclient doesn't receive DHCP offers from kernel ("No DHCPOFFERS received")**Describe the bug**
Once in a while, dhclient sends DHCPDISCOVER but never receives any replies. This causes the machine to fail to acquire an IPv4 address.
**To Reproduce**
Steps to reproduce the behavior:
1. Boot a machine running De...**Describe the bug**
Once in a while, dhclient sends DHCPDISCOVER but never receives any replies. This causes the machine to fail to acquire an IPv4 address.
**To Reproduce**
Steps to reproduce the behavior:
1. Boot a machine running Debian 11 with isc-dhcp-client 4.4.1-2.3.
2. Wait a minute or so, and observe logs like:
```
debian dhclient[334]: Internet Systems Consortium DHCP Client 4.4.1
debian dhclient[334]: Copyright 2004-2018 Internet Systems Consortium.
debian dhclient[334]: All rights reserved.
debian dhclient[334]: For info, please visit https://www.isc.org/software/dhcp/
debian dhclient[334]:
debian dhclient[334]: Listening on LPF/ens4/42:01:0a:8a:00:71
debian dhclient[334]: Sending on LPF/ens4/42:01:0a:8a:00:71
debian dhclient[334]: Sending on Socket/fallback
debian dhclient[334]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 6
debian dhclient[334]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 7
debian dhclient[334]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 13
debian dhclient[334]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 21
debian dhclient[334]: DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 14
debian dhclient[334]: No DHCPOFFERS received.
```
**Expected behavior**
Machine comes up with IPv4 address assigned.
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Debian 11 bullseye
- Which features were compiled in: not sure. It comes from the official repos: https://packages.debian.org/bullseye/isc-dhcp-client
**Additional Information**
Someone else reported what seems to be the same issue on debian isc-dhcp-client issue tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996356
**Participating in development**
I'm happy to discuss the issue.
**Contacting you**
Please reach out via github if I don't respond here.https://gitlab.isc.org/isc-projects/dhcp/-/issues/260dhclient: bond master not getting IP, but slave interface does.2022-09-05T14:40:05ZRama krishnadhclient: bond master not getting IP, but slave interface does.---
name: Bug report
about: bond master not getting IP, but slave interface does.
---
**Describe the bug**
dhclient: if the interface goes down before exit-hook getting executed, the successive DHCP requests doesn't work
**To Reprodu...---
name: Bug report
about: bond master not getting IP, but slave interface does.
---
**Describe the bug**
dhclient: if the interface goes down before exit-hook getting executed, the successive DHCP requests doesn't work
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient with an exit-hook
2. Even before the exit-hook starts executed, bring down the port and add to bond
3. run dhclient -r to release IP
4. Bring the slave interface up, though it's a slave, ip gets assigned.
5. But the master bond interface doesn't get IP from DHCP
**Expected behavior**
The bond, which is the master of the interface has to get Ip, instead of slave port
**Environment:**
- busybox 1.31.0
- Internet Systems Consortium DHCP Client 4.4.1
**Additional Information**
**Logs:**
```
Jul 2 17:17:31 myDevice dhclient: Registering interface:intf0 for messages
Jul 2 17:17:31 myDevice dhclient: DHCPDISCOVER on intf0 to 255.255.255.255 port 67 interval 5
Jul 2 17:17:36 myDevice dhclient: DHCPDISCOVER on intf0 to 255.255.255.255 port 67 interval 12
Jul 2 17:17:45 myDevice kernel: [ 78.608532] myEth 0000:00:03.0 intf0: Link up at 100 Gb/s full-duplex, RS-FEC
Jul 2 17:17:45 myDevice kernel: [ 78.608783] IPv6: ADDRCONF(NETDEV_CHANGE): intf0: link becomes ready
Jul 2 17:17:48 myDevice dhclient: DHCPDISCOVER on intf0 to 255.255.255.255 port 67 interval 15
Jul 2 17:17:48 myDevice dhclient: DHCPOFFER of 15.33.55.2 from 15.33.55.1
Jul 2 17:17:48 myDevice dhclient: DHCPREQUEST for 15.33.55.2 on intf0 to 255.255.255.255 port 67
Jul 2 17:17:48 myDevice dhclient: DHCPACK of 15.33.55.2 from 15.33.55.1
**<interface going down before exit-hook gets executed.>**
Jul 2 17:17:54 myDevice kernel: [ 87.334025] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Jul 2 17:17:54 myDevice kernel: [ 87.352031] device: 'bond0': device_add
Jul 2 17:17:54 myDevice kernel: [ 87.352277] PM: Adding info for No Bus:bond0
Jul 2 17:17:54 myDevice kernel: [ 87.368921] 8021q: adding VLAN 0 to HW filter on device bond0
Jul 2 17:17:54 myDevice kernel: [ 87.696975] myEth 0000:00:03.0 intf0: Link down
Jul 2 17:17:54 myDevice kernel: [ 87.697917] bond0: (slave intf0): Enslaving as a backup interface with a down link
**<executed dhclient -r to release the IP>**
Jul 2 17:17:54 myDevice dhclient: Allocating configured interace:intf0
Jul 2 17:17:54 myDevice dhclient: Killed old client process
…
Jul 2 17:17:55 myDevice dhclient: Processing interface:eth0.2
Jul 2 17:17:55 myDevice dhclient: Processing interface:vlan1
Jul 2 17:17:55 myDevice dhclient: Registering interface:intf0 for messages
**<exit hook for old bound>**
Jul 2 17:17:59 myDevice /sbin/dhclient-script: /etc/dhclient-exit-hooks.d/opion67-bootfile
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export OLDPWD
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export PATH="/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export PWD="/"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export SHLVL="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export dad_wait_time="0"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export interface="intf0"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_broadcast_address="15.33.55.255"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_dhcp_lease_time="600"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_dhcp_message_type="5"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_dhcp_server_identifier="15.18.1.101"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_domain_name=“xyzzy”
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_domain_name_servers="10.1.20.200 10.1.20.201"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_expiry="1656782868"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_ip_address="15.33.55.2"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_network_number="15.33.55.0"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_next_server="15.18.1.101"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_routers="15.33.55.1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export new_subnet_mask="255.255.255.0"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export pid="962"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export reason="BOUND"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_bootfile_name="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_broadcast_address="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_classless_static_routes="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_domain_name="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_domain_name_servers="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_host_name="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_netbios_name_servers="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_netbios_scope="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_routers="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_subnet_mask="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: export requested_time_offset="1"
Jul 2 17:17:59 myDevice /sbin/dhclient-script: Ignore interface intf0 without bootfile
Jul 2 17:18:09 myDevice kernel: [ 101.807641] myEth 0000:00:03.0 intf0: Link up at 100 Gb/s full-duplex, RS-FEC, dormant
Jul 2 17:18:09 myDevice kernel: [ 101.807864] myEth 0000:00:03.0 intf0: Link up at 100 Gb/s full-duplex, RS-FEC
Jul 2 17:18:09 myDevice kernel: [ 101.848030] bond0: (slave intf0): link status definitely up, 100000 Mbps full duplex
Jul 2 17:18:09 myDevice kernel: [ 101.848258] bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
Jul 2 17:18:09 myDevice kernel: [ 101.848509] bond0: active interface up!
Jul 2 17:18:09 myDevice kernel: [ 101.848820] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
**<even though bond is up, slave has obtained the IP>**
Jul 2 17:18:13 myDevice ntpd[1415]: Listen normally on 11 intf0 15.33.55.2:123
Jul 2 17:18:13 myDevice ntpd[1415]: Listen normally on 12 bond0 [fe80::nnnn%31]:123
Jul 2 17:18:13 myDevice ntpd[1415]: new interface(s) found: waking up resolver
```
**Is your feature request related to a problem? Please describe.**
Few observations:
1. the exit hook is taking long time to execute
2. after executing "dhclinet -r" the IP is not released
**Describe the solution you'd like**
The bond, which is the master has to get Ip, instead of slave port
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
NO
**Contacting you**
bsramakrishna91@gmail.comhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/259Can't create host with omshell for option82 circuit id2022-09-03T00:00:00ZWyatt ZochertCan't create host with omshell for option82 circuit idTrying to use OMshell to create a host on DHCP 4.4.1 on Ubuntu 22 LTS with a circuit-id as the key. OMShell says it is an invalid argument. Also had this on earlier versions, upgrading did not help. Creating hosts keyed by MAC is fine...Trying to use OMshell to create a host on DHCP 4.4.1 on Ubuntu 22 LTS with a circuit-id as the key. OMShell says it is an invalid argument. Also had this on earlier versions, upgrading did not help. Creating hosts keyed by MAC is fine.
```
test@testdhcp:$ dhcpd --version
isc-dhcpd-4.4.1
test@testdhcp:$ omshell
> server localhost
> port 7911
> key omapikey ********
> connect
obj: <null>
> new host
obj: host
> set name = "TestCID3"
obj: host
name = "TestCID3"
> set ip-address = 192.168.240.59
obj: host
name = "TestCID3"
ip-address = c0:a8:f0:3b
> set statements = "host-identifier option agent.circuit-id \"TestCID3\";"
obj: host
name = "TestCID3"
ip-address = c0:a8:f0:3b
statements = "host-identifier option agent.circuit-id "TestCID3";"
> create
can't open object: invalid argument
obj: host
name = "TestCID3"
ip-address = c0:a8:f0:3b
statements = "host-identifier option agent.circuit-id "TestCID3";"
>
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/256Please update config.guess to support RISC-V2022-11-04T15:53:04ZFantasqueXPlease update config.guess to support RISC-VHi, I'm building Bind9 on RISC-V. However, I met some error when executing `./configure` in unpacked release tarball.
```
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
che...Hi, I'm building Bind9 on RISC-V. However, I met some error when executing `./configure` in unpacked release tarball.
```
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... ./config.guess: unable to guess system type
This script, last modified 2013-06-10, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed
information to handle your system.
config.guess timestamp = 2013-06-10
uname -m = riscv64
uname -r = 5.15.10+
uname -s = Linux
uname -v = #1 SMP Fri Dec 24 14:24:27 CST 2021
/usr/bin/uname -p = unknown
/bin/uname -X =
hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch =
/usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = riscv64
UNAME_RELEASE = 5.15.10+
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP Fri Dec 24 14:24:27 CST 2021
configure: error: cannot guess build type; you must specify one
```
As far as I know, a more recent version of config.guess can recognize RISC-V. So could you please update config.guess and config.sub to support RISC-V?https://gitlab.isc.org/isc-projects/dhcp/-/issues/255dhclient incompatible with network namespaces using /etc/netns/resolv.conf2022-08-19T21:03:28ZBryan "Crypt0s" Halfpapdhclient incompatible with network namespaces using /etc/netns/resolv.conf---
name: Bug report
about: Create a report to help us improve
**Describe the bug**
dhclient-script is fails to set /etc/resolv.conf when used in a ip-netns network namespace which is overriding the network namespace /etc/resolv.conf ...---
name: Bug report
about: Create a report to help us improve
**Describe the bug**
dhclient-script is fails to set /etc/resolv.conf when used in a ip-netns network namespace which is overriding the network namespace /etc/resolv.conf file. This results in partial dhcp configuration for the system (dns information is not set).
**To Reproduce**
On a linux host, assuming that eth0 exists and is connected to a network which supports dhcp addressing:
```
mkdir -p /etc/netns/test/
echo "nameserver 1.1.1.1" > /etc/netns/test/resolv.conf
ip netns add test
ip link set eth0 netns test
ip netns exec test cat /etc/resolv.conf
ip netns exec test dhclient /etc/resolv.conf
```
Note that the dhclient will return a `mv` error
**Expected behavior**
The dhclient procedure should set the /etc/resolv.conf properly within the namespace.
**Environment:**
- ISC DHCP version 4.4.1
- OS: x86_64 Ubuntu 20.04.4
**Additional Information**
The dhclient-script file for at least linux (https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux) is currently incompatible with configurations of ip-netns (network namespaces) in which ip-netns controls /etc/resolv.conf. This is because ip-netns mounts (and prevents deletion/moving of) a configuration file from /etc/netns/NAMESPACE/resolv.conf at /etc/resolv.conf within the namespace, where NAMESPACE in the path is replaced with the name of the ip-netns network namespace.
When this configuration is being used, the ISC-provided dhclient-script will fail on the `mv -f $new_resolv_conf /etc/resolv.conf` operations ([text](https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L80) and [text](https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L107)) and therefore fails to update the DNS service.
While this may not be purely a ISC-DHCP package issue, a one-to-one behavior fix could be adopted. Instead of using `mv -f`, a `cp` and `rm` command can be used to copy and then remove the temporary resolv.conf file generated by ISC-DHCP. This would neatly implement the fix and allow behavior in both ISC-DHCP and ip-netns to continue without modification.
I've produced an example patch here for the linux script: [text](https://github.com/Crypt0s/dhcp/commit/b367afac3628bfb05f0d866654edffe26600348d)
I include the ip-netns reference to the /etc/resolv.conf behavior below for convenience:
[text](https://man7.org/linux/man-pages/man8/ip-netns.8.html)
For applications that are aware of network namespaces, the
convention is to look for global network configuration files
first in /etc/netns/NAME/ then in /etc/. For example, if you
want a different version of /etc/resolv.conf for a network
namespace used to isolate your vpn you would name it
/etc/netns/myvpn/resolv.conf.
ip netns exec automates handling of this configuration, file
convention for network namespace unaware applications, by
creating a mount namespace and bind mounting all of the per
network namespace configure files into their traditional location
in /etc.
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
yes - this references MASTER branch.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
This behavior should be considered for modified since dhclient is still heavily leveraged in most linux flavors by default
- Are you sure what you would like to do is not possible using some other mechanisms?
ip-netns behavior /could/ be modified but this change does not modify dhclient-script's behavior.
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
no
**Participating in development**
I have produced a patch included above.
**Contacting you**
Github (Crypt0s) or email (bryanhalf@gmail.com)https://gitlab.isc.org/isc-projects/dhcp/-/issues/252A potential null reference in dhcp project2022-07-22T12:34:42ZPeter DaviesA potential null reference in dhcp projectThe following was received on Thursday 14th July 2022 by Security Officer from Victor Tom <vv474172261@gmail.com>
Hi,
in function parse_executable_statements:
```c
int parse_executable_statements (statements, cfile, lose, case_context)...The following was received on Thursday 14th July 2022 by Security Officer from Victor Tom <vv474172261@gmail.com>
Hi,
in function parse_executable_statements:
```c
int parse_executable_statements (statements, cfile, lose, case_context)...
{
next = statements;
while (parse_executable_statement (next, cfile, lose, case_context))
next = &((*next) -> next);
...
}
```
it assumes `parse_executable_statement` will return 1 with setting statements.
However, in function parse_executable_statement:
```c
switch(token){
case EVAL:
skip_token(&val, (unsigned *)0, cfile);
if (!executable_statement_allocate (result, MDL))
log_fatal ("no memory for eval statement.");
(*result) -> op = eval_statement;
if (!parse_expression (&(*result) -> data.eval,
cfile, lose, context_data, /* XXX */
(struct expression **)0, expr_none)) {
if (!*lose)
parse_warn (cfile,
"expecting data expression.");
else
*lose = 1;
skip_to_semi (cfile);
executable_statement_dereference (result, MDL);
return 0;
}
if (!parse_semi (cfile)) { <<<<<<<<<L0
*lose = 1;
executable_statement_dereference (result, MDL); <<<<<<<<<<L1
}
break;
}
return 1;
```
if case is EVAL, and parse_semi(cfile) returns 0 at Lable L0, it will derefer result and free result and set it to 0.
This is unexcepted by parse_executable_statements. Thus, it may refer to a NULL pointer.
I don't have a poc, but this situation is expected if we can control cfile's content.
Regards,
VictorV of Cyber Kunlun Lab