dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-09-23T22:30:55Zhttps://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/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/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/121ISC-DHCP-Server appears abandoned on Ubuntu focal2021-06-10T16:12:44ZAndrew WelhamISC-DHCP-Server appears abandoned on Ubuntu focalIs the ISC-DHCP-Server for Ubuntu 20.04 abandoned ?
The reason for asking is there appear to be no updates since April 2020, and there are critical issues for example you can't launch ISC-DHCP in a cluster on Focal 20.04.
There are al...Is the ISC-DHCP-Server for Ubuntu 20.04 abandoned ?
The reason for asking is there appear to be no updates since April 2020, and there are critical issues for example you can't launch ISC-DHCP in a cluster on Focal 20.04.
There are also lots of reports left in undecided, with no activity that i can see of.
for example
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118
I've email the maintainer and no response.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/94DHCP relay agent will not discover interfaces if they are down when dhcrelay ...2022-03-09T19:03:52ZJoe LeVequeDHCP relay agent will not discover interfaces if they are down when dhcrelay startsCurrently, dhcrelay will not discover interfaces if they are down at the time the relay agent starts up. If the interface(s) are down at the moment dhcrelay enumerates the interfaces, yet they get brought up any time later, the relay wil...Currently, dhcrelay will not discover interfaces if they are down at the time the relay agent starts up. If the interface(s) are down at the moment dhcrelay enumerates the interfaces, yet they get brought up any time later, the relay will discard packets received on these interfaces and log the message, `Discarding packet received on <iface_name> interface that has no IPv4 address assigned`.
With this patch, the relay agent will discover all configured interfaces, whether or not they are up at the time the relay agent starts. Thus, the state of the configured interfaces can be down when the relay agent starts and brought up during the lifetime of the relay agent process, and the relay agent will relay packets as expected; it will not discard them. A DHCP relay agent shouldn't ignore a configured interface if the interface happens to be down when it starts up.
The patch is the addition of one line in common/discover.c, after line 638.
Current code:
```c
/* Skip non broadcast interfaces (plus loopback and
point-to-point in case an OS incorrectly marks them
as broadcast). Also skip down interfaces unless we're
trying to get a list of configurable interfaces. */
if ((((local_family == AF_INET &&
!(info.flags & IFF_BROADCAST)) ||
#ifdef DHCPv6
(local_family == AF_INET6 &&
!(info.flags & IFF_MULTICAST)) ||
#endif
info.flags & IFF_LOOPBACK ||
info.flags & IFF_POINTOPOINT) && !tmp) ||
(!(info.flags & IFF_UP) &&
state != DISCOVER_UNCONFIGURED))
continue;
```
Proposed patch:
```c
/* Skip non broadcast interfaces (plus loopback and
point-to-point in case an OS incorrectly marks them
as broadcast). Also skip down interfaces unless we're
trying to get a list of configurable interfaces. */
if ((((local_family == AF_INET &&
!(info.flags & IFF_BROADCAST)) ||
#ifdef DHCPv6
(local_family == AF_INET6 &&
!(info.flags & IFF_MULTICAST)) ||
#endif
info.flags & IFF_LOOPBACK ||
info.flags & IFF_POINTOPOINT) && !tmp) ||
(!(info.flags & IFF_UP) &&
state != DISCOVER_UNCONFIGURED &&
state != DISCOVER_RELAY))
continue;
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/88Bug in dhcpd with ipv6 and network interface aliases2021-08-24T14:28:14ZGhost UserBug in dhcpd with ipv6 and network interface aliases
Hi
We have detected a problem when using dhcpdv6 when there are messages received from an IPv6 interface (eth0) which has an interface alias (eth0:0) [1]. dhcpd tries to answer using the alias and fails with a bad file descriptor bec...
Hi
We have detected a problem when using dhcpdv6 when there are messages received from an IPv6 interface (eth0) which has an interface alias (eth0:0) [1]. dhcpd tries to answer using the alias and fails with a bad file descriptor because eth0 and eth0:0 have the same interface index, so the following patch ignores interfaces with invalid write file descriptors.
Cheers
Alejandro.
[1]
```
# ifconfig
eth0 Link encap:Ethernet HWaddr A
inet addr:B Bcast:C Mask:255.255.255.0
inet6 addr: D/64 Scope:Global
inet6 addr: D/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7182898 errors:0 dropped:22 overruns:0 frame:0
TX packets:4863373 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3551746525 (3.5 GB) TX bytes:4883184122 (4.8 GB)
eth0:0 Link encap:Ethernet HWaddr A
inet addr:E Bcast:F Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
```
**To Reproduce**
1. Run dhcpd with a ip pool in eth0 in ipv6 and a interface alias eth0:0
```
/usr/sbin/dhcpd -d -6 -user dhcpd -group dhcpd -cf /etc/dhcp/dhcpd6.conf --no-pid
```
2. A client does a IPv6 request and doesn't gets an answer.
3. The server doesn't answer.
4. See error
```
Sending Relay-reply to XX::XX port 547
send_packet6: Bad file descriptor
dhcpv6: send_packet6() sent -1 of 239 bytes
```
**Expected behavior**
The server is supposed to send back packet A with address B assigned.
**Environment:**
- ISC DHCP version: isc-dhcpd-4.4.1
- OS: Debian buster
**Additional Information**
gdb shows that ```if_nametoindex(ip->name)``` is equal for eth0 and eth0:0. But eth0:0 does not have a valid file descriptor.
[patch.patch](/uploads/b4773b08980a36cfc4d7a40a3d0b23d5/patch.patch)4.5.0-betahttps://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.