dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-03-14T07:18:21Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/180Not buildable on OpenWRT2022-03-14T07:18:21ZPhilip PrindevilleNot buildable on OpenWRT**Not buildable on OpenWRT**
4.2.2 won't build on OpenWRT because it's not finding `<isc/boolean.h>`.
**To Reproduce**
Steps to reproduce the behavior:
1. Checkout `master` on `openwrt/packages`, and change `net/isc-dhcp/Makefile` to us...**Not buildable on OpenWRT**
4.2.2 won't build on OpenWRT because it's not finding `<isc/boolean.h>`.
**To Reproduce**
Steps to reproduce the behavior:
1. Checkout `master` on `openwrt/packages`, and change `net/isc-dhcp/Makefile` to use version `4.4.2`.
2. Build
3. See error
4.
**Expected behavior**
It should build as 4.4.1 did.
**Environment:**
- ISC DHCP version: 4.4.2
- OS: OpenWRT master cross-built on Ubuntu 20.04.02 LTS
- `CONFIG_PACKAGE_isc-dhcp-server-ipv6=y` should be configured
**Additional Information**
Build fails as:
```
make[5]: Entering directory '/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2/common'
x86_64-openwrt-linux-musl-gcc -DHAVE_CONFIG_H -I. -I../includes -I.. -DLOCALSTATEDIR='"/var"' -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/usr/include -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/include/fortify -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/include -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2=dhcp-4.4.2 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fcommon -I../includes -I/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2/bind/include -c -o alloc.o alloc.c
In file included from ../includes/dhcpd.h:91,
from alloc.c:29:
../includes/omapip/isclib.h:51:10: fatal error: isc/boolean.h: No such file or directory
#include <isc/boolean.h>
^~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [Makefile:504: alloc.o] Error 1
make[5]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2/common'
make[4]: *** [Makefile:563: all-recursive] Error 1
make[4]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2/common'
make[3]: *** [Makefile:464: all-recursive] Error 1
make[3]: Leaving directory '/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2'
make[2]: *** [Makefile:301: /home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.2/.built] Error 2
make[2]: Leaving directory '/home/philipp/lede/feeds/packages/net/isc-dhcp'
time: package/feeds/packages/isc-dhcp/ipv6/compile#93.82#21.71#108.97
ERROR: package/feeds/packages/isc-dhcp failed to build (build variant: ipv6).
make[1]: *** [package/Makefile:114: package/feeds/packages/isc-dhcp/compile] Error 1
```
See also: [OpenWRT PR 14605](https://github.com/openwrt/packages/pull/14605/files)
**Is your feature request related to a problem? Please describe.**
This doesn't cross-build any more.
**Describe the solution you'd like**
`common/Makefile.am` should include settings from `../make/includes` but doesn't.
**Describe alternatives you've considered**
See previous
**Additional context**
N/A
**Funding its development**
N/A
**Participating in development**
I'm the maintainer for ISC-DHCP in OpenWRT, so not sure what more I need to do here...
**Contacting you**
My email is listed on my gitlab account, plus you can find me on the mailing lists.4.4.3-beta1https://gitlab.isc.org/isc-projects/dhcp/-/issues/232Sanity Check 4.4.3 rc12022-03-08T13:34:04ZWlodzimierz WencelSanity Check 4.4.3 rc1Let's do some sanity checks :)
```
@repo /data/shared/sweng/dhcp/releases/4.4.3rc1]$ sha256 dhcp-4.4.3.tar.gz
SHA256 (dhcp-4.4.3.tar.gz) = 0e3ec6b4c2a05ec0148874bcd999a66d05518378d77421f607fb0bc9d0135818
```Let's do some sanity checks :)
```
@repo /data/shared/sweng/dhcp/releases/4.4.3rc1]$ sha256 dhcp-4.4.3.tar.gz
SHA256 (dhcp-4.4.3.tar.gz) = 0e3ec6b4c2a05ec0148874bcd999a66d05518378d77421f607fb0bc9d0135818
```4.4.3https://gitlab.isc.org/isc-projects/dhcp/-/issues/225Dev guide update: building ATF tests2022-10-20T09:42:01ZTomek MrugalskiDev guide update: building ATF testsThe developer's guide explains how to build old ATF 0.19. Sadly, to compile it on newer systems, such as Ubuntu 21.04, a small patch is needed to atf sources. This should be documented.The developer's guide explains how to build old ATF 0.19. Sadly, to compile it on newer systems, such as Ubuntu 21.04, a small patch is needed to atf sources. This should be documented.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/219dhcp-lease-list incorrect instruction for downloading the OUI.TXT file from IEEE2022-01-28T11:59:15ZKeith Siemandhcp-lease-list incorrect instruction for downloading the OUI.TXT file from IEEE---
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**
Cosmetic bug. When running the dhcp-lease-list command, the wrong URL is referenced for downloading the OUI file. It is currently set to read http://standards.ieee.org/regauth/oui/oui.txt when it should be http://standards-oui.ieee.org/oui/oui.txt.
**To Reproduce**
Steps to reproduce the behavior:
1. Run the command dhcp-lease-list on a new install of DHCPD with no OUI.TXT file loaded/available.
**Expected behavior**
A clear and concise description of what you expected to happen:
The instruction instead reads:
To get manufacturer names please download http://standards-oui.ieee.org/oui/oui.txt to /usr/local/etc/oui.txt
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Raspbian 11 (bullseye)
- Which features were compiled in: Installed from apt
**Additional Information**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
|- No, on 4.4.1 and latest version is 4.4.2-PL1, however this is not obtainable via apt on Raspbian just yet.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
|- Unknown, but not sure if relevant.
- Are you sure what you would like to do is not possible using some other mechanisms?
|- Irrelevant.
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
|- No.
**Is your feature request related to a problem? Please describe.**
N/A
**Describe the solution you'd like**
The correct URL displays
**Describe alternatives you've considered**
The user can Google it
**Additional context**
N/A
**Funding its development**
N/A
**Participating in development**
N/A
**Contacting you**
E-mail attached to this account is fine4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/227Remove client and relay code2022-03-30T14:57:07ZTomek MrugalskiRemove client and relay codeThe client (`dhclient`) and relay (`dhcrelay`) reached its end of life. The %"4.4.3" was the last release that had them.
Now it's time to remove the code and documentation for it.The client (`dhclient`) and relay (`dhcrelay`) reached its end of life. The %"4.4.3" was the last release that had them.
Now it's time to remove the code and documentation for it.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/211Preload oui.txt in dhcp-lease-list-pl for significantly improved runtimes2022-01-28T19:32:27ZbretgiddingsPreload oui.txt in dhcp-lease-list-pl for significantly improved runtimesThe current dhcp-lease-list.pl script uses grep to lookup oui's. If you are reading oui's for more than 1 lease, it is more than likely that pre-loading the file into a perl hash keyed on the first three octets of the mac will improve pe...The current dhcp-lease-list.pl script uses grep to lookup oui's. If you are reading oui's for more than 1 lease, it is more than likely that pre-loading the file into a perl hash keyed on the first three octets of the mac will improve performance. Simple tests show that doing this with 50 valid leases will be 5 times faster. For 1000 leases, the speedup is of the order of 100 time faster - indeed, with the hashed file, 1000 leases is still significantly faster than 50 leases without the hashed data.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/164Allow update-conflict-detection to be specified at class scope2022-09-07T12:48:23ZThomas MarkwalderAllow update-conflict-detection to be specified at class scopeThe implementation of DSMM in 4.4.0, limited the scope of update-conflict-detection to global scope only. We have a request from a support customer to expand to support at least class-scope:
https://support.isc.org/Ticket/Display.html?...The implementation of DSMM in 4.4.0, limited the scope of update-conflict-detection to global scope only. We have a request from a support customer to expand to support at least class-scope:
https://support.isc.org/Ticket/Display.html?id=17904
Customer is willing to use a patch, if we can develop one.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/146Add support for raw IP interface type2020-12-03T10:15:34ZFrancis DupontAdd support for raw IP interface typeSee !66 (issue created to host it).See !66 (issue created to host it).4.5.0-betaFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/135Virtual interface support2020-11-12T20:43:18ZFrederic BorVirtual interface support---
name: Virtual interface support
about: with the rise of VTI IPsec usage, there is a need for virtual interface support in dhcp relay.
---
**Is your feature request related to a problem? Please describe.**
I would like to use a rem...---
name: Virtual interface support
about: with the rise of VTI IPsec usage, there is a need for virtual interface support in dhcp relay.
---
**Is your feature request related to a problem? Please describe.**
I would like to use a remote dhcp server and relay request to it threw VTI interfaces.
**Describe the solution you'd like**
I'd like to have support for virtual interfaces so I can relay dhcp requests threw them.
**Describe alternatives you've considered**
The only alternative when using VTI is to have a local dhcp server, instead of a remote one. But when you start to have some small remote sites, it's a lot less convenient than simply activate dhcp relay and setting up the ip of the remote server.
**Additional context**
The attached patch is implementing this for IFT_TUNNEL interface type.
I had some trouble with BPF, getting the whole packet. I was only having the first 67 bytes. I'm not sure why. It was working correctly in a small POC code environnement but not within dhcrelay. I managed do get it works by adding a "load (uint)(-1) into the accumulator" instruction before returning the packet.
We are using this patch in production since march on a dozen of firewalls, it's working well. It's untested except on pfSense/FreeBSD.
**Participating in development**
I am willing to participate in the feature development, discusions, tests.
I will see how to do this on linux.
Could I have a project allocation to this intent ?
**Contacting you**
Here is nice, or github.
[vti_support.patch](/uploads/0d96555a7ae7eec4a4c537079f364c28/vti_support.patch)4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/128DHCP cluster crashes after a few hours2022-01-13T11:24:31ZRichard LaagerDHCP cluster crashes after a few hours**Describe the bug**
When running a cluster using dhcpd 4.4.1 or 4.4.2, at least with Ubuntu patches, dhcpd crashes after a few hours.
Here are two instances of the crash with the packaged 4.4.1 from Ubuntu 20.04:
```
2020-07-31T06:28:...**Describe the bug**
When running a cluster using dhcpd 4.4.1 or 4.4.2, at least with Ubuntu patches, dhcpd crashes after a few hours.
Here are two instances of the crash with the packaged 4.4.1 from Ubuntu 20.04:
```
2020-07-31T06:28:28.138646-05:00 salmon sh[764]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace
2020-07-31T06:28:28.138704-05:00 salmon sh[764]: #0 0x7fdd3f4b4a4a in ??
2020-07-31T06:28:28.138768-05:00 salmon sh[764]: #1 0x7fdd3f4b4980 in ??
2020-07-31T06:28:28.138809-05:00 salmon sh[764]: #2 0x7fdd3f4f07e1 in ??
2020-07-31T06:28:28.138849-05:00 salmon sh[764]: #3 0x7fdd3f297609 in ??
2020-07-31T06:28:28.138887-05:00 salmon sh[764]: #4 0x7fdd3f3d3103 in ??
2020-07-31T07:02:54.013649-05:00 salmon sh[32432]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace
2020-07-31T07:02:54.013674-05:00 salmon sh[32432]: #0 0x7fb12a7e0a4a in ??
2020-07-31T07:02:54.013693-05:00 salmon sh[32432]: #1 0x7fb12a7e0980 in ??
2020-07-31T07:02:54.013711-05:00 salmon sh[32432]: #2 0x7fb12a81c7e1 in ??
2020-07-31T07:02:54.013728-05:00 salmon sh[32432]: #3 0x7fb12a5c3609 in ??
2020-07-31T07:02:54.013753-05:00 salmon sh[32432]: #4 0x7fb12a6ff103 in ??
```
**To Reproduce**
At this point, I'm not certain that it has to be a cluster configuration, but everyone reporting it (including me) seems to be running a cluster.
It's also not clear how much configuration is relevant either.
For me, it crashes within a couple of hours on the secondary system.
**Expected behavior**
dhcpd does not crash.
**Environment:**
- ISC DHCP version: 4.4.1 as packaged by Ubuntu (4.4.1-2.1ubuntu5) or 4.4.2 with the same Ubuntu patches as 4.4.1-2.1ubuntu5
- OS: Ubuntu 20.04 x64
The version from 18.04, 4.3.5-3ubuntu7.1, is fine.
**Additional Information**
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118
and before that
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1870729
I am not the original reporter of either of those.
**Some initial questions**
**Contacting you**
Here is fine, or the Ubuntu bug, or rlaager@wiktel.com by email or XMPP. BTW, this item on the template references github, but you're now running your own GitLab instance, so that's probably old.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/125Server startup slow under BSD with many interfaces2020-08-07T16:05:04ZNick RogersServer startup slow under BSD with many interfaces---
name: dhcpd startup is terribly slow under BSD with hundreds or thousands of interfaces
about: the startup is slow because getifaddrs() is walked for all interfaces O(n^2)
---
**Describe the bug**
When running dhcpd under FreeBSD, ...---
name: dhcpd startup is terribly slow under BSD with hundreds or thousands of interfaces
about: the startup is slow because getifaddrs() is walked for all interfaces O(n^2)
---
**Describe the bug**
When running dhcpd under FreeBSD, bpf.c relies on getifaddrs() to determine the MAC address of each interface. getifaddrs() ends up being iterated entirely for each interface, yielding O(n^2) performance. This is not that big of a deal until you have hundreds or thousands of interfaces (e.g. VLANs) and the restart takes too long (30seconds) for a production network.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd on thousands of interfaces
**Expected behavior**
The startup time is very slow until the daemon responds on BPFs
**Environment:**
- ISC DHCP version: 4.4.2
- OS: FreeBSD 12.1 from FBSD ports
- Standard net/isc-dhcp44-server port4.5.0-betahttps://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/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/86dhcpd does not do option 54 (Server Identifier) in certain situations2021-01-25T00:28:24ZGhost Userdhcpd does not do option 54 (Server Identifier) in certain situations**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd with the following config 'interface devnet;' where devnet is a VLAN. Upon starting dhcpd no physical Ethernet interface is connected yet (e.g. un-docked notebook). Albeit th...**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd with the following config 'interface devnet;' where devnet is a VLAN. Upon starting dhcpd no physical Ethernet interface is connected yet (e.g. un-docked notebook). Albeit this being logged as 'dhcpd[1345]: devnet missing an interface
address' dhcpd does successfully start.
2. Notebook gets connected to an Ethernet where Embedded Linux boards are connected via a switched VLAN.
3. A client (e.g. connman running on one of them Embedded Linux targets) does send a DHCP Discover packet
4. The server then responds with a DHCP Offer packet missing option 54 (Server Identifier). Unsure whether or not this may even be illegal according to spec.
4. Unfortunately, connman seems to crash (this is a separate issue to be reported at resp. upstream project).
**Expected behavior**
The dhcpd should never send DHCP Offer packets missing option 54 (Server Identifier).
**Environment:**
- ISC DHCP version: isc-dhcpd-4.4.1 (dhcp-server-4.4.1-19.fc31.x86_64).
- OS: Fedora 31 x64
- Which features were compiled in
http://rpmfind.net/linux/RPM/fedora/updates/31/x86_64/Packages/d/dhcp-server-4.4.1-19.fc31.x86_64.html
**Additional Information**
A colleague of mine once already enquired about this (see below original message) but never got any response.
-------- Original Message --------
Subject: dhcpd does not option 54 (Server Identifier) in certain
situations
Date: 2018-05-09 17:42
From: Stefan Agner <stefan@agner.ch>
To: dhcp-bugs@isc.org
Hello,
When I am using dhcpd 4.4.1 on Linux on a VLAN network interface I can
successfully start the server. When I then connect the Ethernet cable,
dhcpd sends DHCPOFFERs to DHCPDISCOVERs, however they miss option 54.
A quick debug session showed that get_server_source_address gets called
from ack_lease and does not get an address since
packet->interface->address_count is 0.
During startup the DHCP server actually reports the missing interface
address.
Mai 09 17:16:49 trochilidae systemd[1]: Starting IPv4 DHCP server...
Mai 09 17:16:49 trochilidae dhcpd[1345]: Not searching LDAP since
ldap-server, ldap-port and ldap-base-dn were not specified in the
config
Mai 09 17:16:49 trochilidae dhcpd[1345]: Internet Systems Consortium
DHCP Server 4.4.1
Mai 09 17:16:49 trochilidae dhcpd[1345]: Copyright 2004-2018 Internet
Systems Consortium.
Mai 09 17:16:49 trochilidae dhcpd[1345]: All rights reserved.
Mai 09 17:16:49 trochilidae dhcpd[1345]: For info, please visit
https://www.isc.org/software/dhcp/
Mai 09 17:16:49 trochilidae dhcpd[1345]: Source compiled to use
binary-leases
Mai 09 17:16:49 trochilidae dhcpd[1345]: Wrote 0 deleted host decls to
leases file.
Mai 09 17:16:49 trochilidae dhcpd[1345]: Wrote 0 new dynamic host decls
to leases file.
Mai 09 17:16:49 trochilidae dhcpd[1345]: Wrote 155 leases to leases
file.
Mai 09 17:16:49 trochilidae dhcpd[1345]: vlaneth0 missing an interface
address
Mai 09 17:16:49 trochilidae dhcpd[1345]: Server starting service.
Mai 09 17:16:49 trochilidae systemd[1]: Started IPv4 DHCP server.
Mai 09 17:17:03 trochilidae dhcpd[1345]: DHCPDISCOVER from
00:14:2d:2d:e4:c9 via vlaneth0
Mai 09 17:17:04 trochilidae dhcpd[1345]: DHCPOFFER on 192.168.10.168 to
00:14:2d:2d:e4:c9 (hostname) via vlaneth0
As far as I can tell DHCP mandates option 54. It seems to me that the
behavior currently is not ideal. The DHCP server should either deny
sending DHCPOFFERs or not start in first place...?
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? No, but at least I could not spot anything relevant in the history since.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration? Good question. Kea is news to me but I will give it a try and update this ticket should our use case work there.
- Are you sure what you would like to do is not possible using some other mechanisms? Well, one could keep manually re-starting dhcpd over and over again...
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? Yes, I'm coming from their suggestion to log this as a bug.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/32undefined symbols in libomapi2023-03-07T09:15:20ZEnrico Scholzundefined symbols in libomapi**Describe the bug**
Calling `dhclient` fails here with
```
dhclient: symbol lookup error: /usr/lib/libomapi.so.0: undefined symbol: dns_rootname
```
This is caused by a combination of `-Wl,-as-needed` and `-Wl,-no-add-nedded` linker...**Describe the bug**
Calling `dhclient` fails here with
```
dhclient: symbol lookup error: /usr/lib/libomapi.so.0: undefined symbol: dns_rootname
```
This is caused by a combination of `-Wl,-as-needed` and `-Wl,-no-add-nedded` linkerflags (although sounding similarly, they have diffierent semantics and latter one is the default e.g. on Fedora).
Because code in `libomapi.so` uses functionality from `libdns` and other libraries, it should be linked against them.
I fixed it with [omapilibs.patch](/uploads/ff0ba07e0db378984318714d188972e0/omapilibs.patch)
```diff
Index: dhcp-4.4.1/omapip/Makefile.am.in
===================================================================
--- dhcp-4.4.1.orig/omapip/Makefile.am.in
+++ dhcp-4.4.1/omapip/Makefile.am.in
@@ -11,6 +11,10 @@ libomapi_@A@_SOURCES = protocol.c buffer
handle.c message.c convert.c hash.c auth.c inet_addr.c \
array.c trace.c toisc.c iscprint.c isclib.c
+libomapi_@A@_LIBADD = $(BINDLIBDNSDIR)/libdns.@A@ \
+ $(BINDLIBIRSDIR)/libirs.@A@ \
+ $(BINDLIBISCCFGDIR)/libisccfg.@A@
+
man_MANS = omapi.3
EXTRA_DIST = $(man_MANS)
```
**Environment:**
- seen with OpenEmbedded `thud` (http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/dhcp?h=thud)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)
```