dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-01-24T18:59:16Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/221RELEASE NOTES update about client,relay being EOL2022-01-24T18:59:16ZTomek MrugalskiRELEASE NOTES update about client,relay being EOLWe need to update the release notes with a clear point about dhclient and dhcrelay being the last release.
Also bump up the version.We need to update the release notes with a clear point about dhclient and dhcrelay being the last release.
Also bump up the version.4.4.3-beta1https://gitlab.isc.org/isc-projects/dhcp/-/issues/218Updated bundled Bind9 to 9.11.362022-01-20T10:32:13ZPhilip PrindevilleUpdated bundled Bind9 to 9.11.36**Describe the bug**
DHCP won't build on OpenWRT due to bind/lib/isc/stats.c being broken in 9.11.14.
**To Reproduce**
Steps to reproduce the behavior:
1. Create an OpenWRT build environment (Ubuntu 20 preferred)
2. Tweak feeds/packages...**Describe the bug**
DHCP won't build on OpenWRT due to bind/lib/isc/stats.c being broken in 9.11.14.
**To Reproduce**
Steps to reproduce the behavior:
1. Create an OpenWRT build environment (Ubuntu 20 preferred)
2. Tweak feeds/packages/net/isc-dhcp/Makefile to use `PKG_VERSION:=4.4.2-P2`, `PKG_RELEASE:=1`, and the correct `PKG_HASH` for the tarball.
3. Enable `CONFIG_PACKAGE_isc-dhcp-server-ipv6=y` in your `.config` file.
4. Run `make world`
**Expected behavior**
Everything should build
**Environment:**
- ISC DHCP version: 4.4.2-P2
- OS: Ubuntu 20.04 cross-building OpenWRT `master`
- `CONFIG_PACKAGE_isc-dhcp-server-ipv6=y` enabled
**Additional Information**
Fixed with [fix variable name in conditional block](https://github.com/isc-projects/bind9/commit/261c84d91d1b4581df9f7f0ec031908299de7726) which hit v9_11_15.
**Some initial questions**
- This issue has been brought up on dhcp-workers previously but is unresolved.
**Is your feature request related to a problem? Please describe.**
Unable to build newer releases for OpenWRT (I'm the package owner on that distro).
**Describe the solution you'd like**
I'd like it to be buildable again.
**Describe alternatives you've considered**
None are applicable since they all involve applying patches to a file that gets extracted from a tarball, which isn't supported by the OpenWRT build machinery.
**Additional context**
See discussion on dhcp-workers mailing list.
**Funding its development**
I can contribute support through providing and testing the fix.
**Participating in development**
See previous.
**Contacting you**
See my gitlab account for an email address.
**UPDATE**: The original ticket was to update to 9.11.15, but the changes now update to 9.11.36.4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/197Improve PRNG in dhclient2022-01-12T13:57:01ZTomek MrugalskiImprove PRNG in dhclientThere is an attack on Google Compute Platform using weak randomization in dhclient publicly available here: https://github.com/irsl/gcp-dhcp-takeover-code-exec.
We became aware of this on 2021-06-30.There is an attack on Google Compute Platform using weak randomization in dhclient publicly available here: https://github.com/irsl/gcp-dhcp-takeover-code-exec.
We became aware of this on 2021-06-30.4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/190dhclient: wrong argument to memcpy2022-01-19T19:01:11ZJan Engelhardtdhclient: wrong argument to memcpyAffects 79110e525e0584d195327d31f4ee67e6a5e2fe7a, affects dhcp-4.4.2.
```
client/dhclient.c:3384: memcpy(&client_identifier.buffer->data + 5 - hw_len,
client/dhclient.c:3389: memcpy(&client_identifier.buffer->data+(1+4),...Affects 79110e525e0584d195327d31f4ee67e6a5e2fe7a, affects dhcp-4.4.2.
```
client/dhclient.c:3384: memcpy(&client_identifier.buffer->data + 5 - hw_len,
client/dhclient.c:3389: memcpy(&client_identifier.buffer->data+(1+4),
```
These two lines look wrong. data is of type char[1] and its equivalent pointer would be char*. You would not want to take the address again, as the type of that (char**) leads to a different effect when adding +5.
The lines should be
```
client/dhclient.c:3384: memcpy(client_identifier.buffer->data + 5 - hw_len,
client/dhclient.c:3389: memcpy(client_identifier.buffer->data+(1+4),
```
If the source had declared `unsigned char data[]` instead of `unsigend char data[1]`, this would have been caught.4.4.3-beta1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/189outdated ISC address in license section in 4.4.2 and 4.1-ESV2022-01-20T11:04:51ZWlodzimierz Wenceloutdated ISC address in license section in 4.4.2 and 4.1-ESVExample from code:
```
/*$
* Copyright (c) 2017 by Internet Systems Consortium, Inc. ("ISC")$
*$
* 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 ...Example from code:
```
/*$
* Copyright (c) 2017 by Internet Systems Consortium, Inc. ("ISC")$
*$
* 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$
* file, You can obtain one at http://mozilla.org/MPL/2.0/.$
*$
* THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES$
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF$
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR$
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES$
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN$
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT$
* OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.$
*$
* Internet Systems Consortium, Inc.$
* 950 Charter Street$
* Redwood City, CA 94063$
* <info@isc.org>$
* https://www.isc.org/$
*$
*/$
```
we have outdated address, either change it to current or remove completely.4.4.3-beta1Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/148OMSHELL Fails when using SHA512/256 as the option2022-01-20T18:55:34ZTim McLaughlinOMSHELL Fails when using SHA512/256 as the option---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I compiled the dhcpd 4.4.2 from source on the ISC website and then created a key using dnnsec-keygen, but I can not get omshell to work with a key b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I compiled the dhcpd 4.4.2 from source on the ISC website and then created a key using dnnsec-keygen, but I can not get omshell to work with a key besides MD5. I have tired this on Redhat 7.9, and CENTOS 8.2 (server with a gui standard installation), but can not get the omshell to accept the configuration, in anything besides MD5, I tried SHA1, SHA256 and SHA512.
I generated keys using dnnsec-keygen, i.e. dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n USER myomapi_key.
The dhcpd was build using the following using --enable-paranoia --enable-debug.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcp (which daemon? dhcpd, dhcrelay, dhclient?) with the following config 'Using Systemd to run the dhcpd daemon with the following command: /usr/local/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -lf /var/lib/dhcpd/dhcpd.leases -user dhcpd -group dhcpd --no-pid'
2. I log into the omshell, manually (this will be scripted at a later point),
server localhost
port 7911
key-algorithm HMAC-SHA512
key myomapi_key "MYKEYGOESHERE...…"
connect
3. The server allows the connection
dhcpd[19236]: omapi_set_value (type, 13 20ce4fc)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (name, 8 20ce5cc)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (algorithm, 28 20ce6ec)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (op, 3)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (rid, 321157262)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (handle, 1)
dhcpd[19236]: ==> success
dhcpd[19236]: omapi_set_value (object, authenticator)
dhcpd[19236]: ==> success
4. I then attempt to make a new host using omshell
new host
set name= "Myhostname:
set hardware-address = MAC-ADDRESSS
set hardware-type = 1
set ip-address = 10.0.0.1
create
I then receive the following error:
omapi_set_value (op, 1)
==> success
omapi_set_value (object, dhcpctl-remote)
==> success
omapi_set_value (create, 1)
==> success
omapi_set_value (exclusive, 1)
==> success
omapi_set_value (type, host)
==> success
omapi_set_value (output-authenticator, authenticator)
==> invalid argument
can't open object: invalid argument
**Expected behavior**
The expected behavior is that the omshell command will create the host reservation in the dhcpd.leases file, the same commands work if I switch the key and key algorithm to MD5, just not any other HMAC type.
**Environment:**
- ISC DHCP version: dhcpd --version
isc-dhcpd-4.4.2
- OS: Red Hat Enterprise Linux Server release 7.9 (Maipo), and entOS Linux release 8.2.2004 (Core)
- Which features were compiled in: --enable-paranoia and --enable-debug
**Additional Information**
Config file is
omapi-port 7911;
key myomapi_key {
algorithm hmac-sha512;
secret "MYKEYWASMREMOVEDFROMHERE";
};
omapi-key xcat_key;
shared-network ens3 {
subnet 10.0.0.0 netmask 255.0.0.0 {
authoritative;
max-lease-time 43200;
min-lease-time 43200;
default-lease-time 43200;
option routers 10.0.0.1;
next-server 10.0.0.1;
option log-servers 10.0.0.1;
option ntp-servers 10.0.0.1;
option domain-name "tesbed.dom";
option domain-name-servers 8.8.8.8;
option interface-mtu 1500;
zone testbed.dom. {
primary 8.8.8.8; myomapi_key;
}
range dynamic-bootp 10.0.0.202 10.0.0.251;
} # 10.0.0.0/8 subnet_end
} # virbr1 nic_end
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 feature was added in 4.4.2
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? No
**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.4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/132Feature request to support IPv6-only Preferred DHCPv4 Option2022-01-03T18:54:13ZJen LinkovaFeature request to support IPv6-only Preferred DHCPv4 Option---
name: IPv6-only Preferred DHCPv4 Option
about: Adding Option 108 support (draft-ietf-dhc-v6only) to the DHCP client
---
**Some initial questions**
The [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only) is wi...---
name: IPv6-only Preferred DHCPv4 Option
about: Adding Option 108 support (draft-ietf-dhc-v6only) to the DHCP client
---
**Some initial questions**
The [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only) is with RFC Editors and will be published as an RFC soon. The IANA allocated the option code 108 recently. AFAIK the ISC DHCP client does not support that option yet.
The [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only) was produced by IETF DHC Working Group.
**Is your feature request related to a problem? Please describe.**
While migrating a network to IPv6-only mode, it might be still required to keep some devices dual-stack still. Separating IPv6-only and dual-stack hosts into different network segment does not scale very well and introduces other challenges. It's rather desirable to allow IPv6-only and dual-stack devices to coexist on the same network segment, and provide IPv4 addresses via DHCPv4 only to hosts which really need IPv4 connectivity. So what we need is a way for a host which can operate in IPv6-only mode to signal its IPv6-only readiness to the DHCPv4 server.
More details could be found in [draft-ietf-dhc-v6only](https://tools.ietf.org/html/draft-ietf-dhc-v6only#section-1)
**Describe the solution you'd like**
The client which is willing to be IPv6-only includes the Option 108 into the PRL. If the server does not support it or the network segment does not provide IPv6-only connectivity, the server does not include the option in the response and the normal DHCPv4 process happens. So the client would receive IPv4 address. However if the network segment is IPv6-only and the server is configured to respond with the Option 108, the server includes the option into DHCPOFFER or DHCPACK. When the client receives the option 108 back, it should stop DHCPv4 process for some time.
More details could be found in:
- [Option format](https://tools.ietf.org/html/draft-ietf-dhc-v6only#section-3.1)
- [Client Behaviour](https://tools.ietf.org/html/draft-ietf-dhc-v6only#section-3.2)
**Describe alternatives you've considered**
While it's possible to achieve the similar results by silently discarding DHCPv4 packets from IPv6-only capable hosts, that approach has a serious drawback: the client never stops asking, so the load on the DHCP infrastructure increases.
**Additional context**
N/A
**Funding its development**
See below
**Participating in development**
While I'm not really proficient at writing C code and I'm not familiar with the ISC codebase, I'm happy to participate. Willing to test the client code indeed.
**Contacting you**
Email or Hangouts: furry13@gmail.com4.4.3-beta1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/123dhclient runs out of all available addresses in the pool in case of abnormal ...2022-01-12T13:30:35ZAleksey Novikovdhclient runs out of all available addresses in the pool in case of abnormal script termination**Preface**
Some Linux distribution, eg. CentOS Linux 7.x or 8.x, use NetworkManager to configure network interfaces. The dhclient command started by NetworkManager looks like this:
```
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-hel...**Preface**
Some Linux distribution, eg. CentOS Linux 7.x or 8.x, use NetworkManager to configure network interfaces. The dhclient command started by NetworkManager looks like this:
```
/sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper \
-pf /run/NetworkManager/dhclient-<iface_name>.pid \
-lf /var/lib/NetworkManager/dhclient-<connection_uuid>-<iface_name>.lease \
-cf /var/lib/NetworkManager/dhclient-<iface_name>.conf <iface_name>
```
When dhclient receive answer from server on lease renewal it use script or binary specified by `-sf` option for IP validity checking.
```
/* If the BOUND/RENEW code detects another machine using the
offered address, it exits nonzero. We need to send a
DHCPDECLINE and toss the lease. */
if (script_go(client)) {
make_decline(client, client->new);
send_decline(client);
destroy_client_lease(client->new);
```
But the `script_go` function return non-zero result in the 2 cases:
1. Launched process exit status is non-zero. In this case `script_go` function return value > 0.
2. Launched process terminated by signal, eg. SIGTEM. In this case `script_go` function return value < 0.
**Problem description**
Let's imagine the next situation. `nm-dhcp-helper` or other script or binary specified by `-sf` option starting at some time will always terminates by SIGSEGV due to filesystem damage or some dynamic library incompatibility. In this case the dhclient will send DECLINE and retry lease renewal after 10 seconds timeout. This will repeat infinitely until all available addresses in the DHCP pool will be marked as invalid and other clients will not be able to lease an IP address.
**Solution**
To eliminate the possibility of a repetition of such a situation, it is enough in the above code fragment to replace a line
```
if (script_go(client)) {
```
by
```
if (script_go(client) > 0) {
```4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/103LICENSE file has confusing preamble2022-01-20T16:13:29ZTomek MrugalskiLICENSE file has confusing preambleThe code is now published under MPL-2.0 license, but the there is extra preamble is slightly confusing.The code is now published under MPL-2.0 license, but the there is extra preamble is slightly confusing.4.4.3-beta1https://gitlab.isc.org/isc-projects/dhcp/-/issues/76Add a version of dhcpctl_wait_completion() that accepts a timeout2022-01-25T19:06:54ZThomas MarkwalderAdd a version of dhcpctl_wait_completion() that accepts a timeoutPer support ticket:
https://support.isc.org/Ticket/Display.html?id=15842
Calling dhcpctl_wait_completion() has two shortcomings:
1. First, it does not provide a timeout parameter and thus may effectively hang
2. Underneath the covers ...Per support ticket:
https://support.isc.org/Ticket/Display.html?id=15842
Calling dhcpctl_wait_completion() has two shortcomings:
1. First, it does not provide a timeout parameter and thus may effectively hang
2. Underneath the covers the way the logic is structured in omapi/dispatch.c, we end up effectively using the select() calls to poll in a tight loop eating CPU.
The first issue is simply address. The latter is a bit more sticky. The select calls are with omapi_dispatch_one(). They monitor the read and write sides of OMAPI connections. However, once the basic socket connection is made, the write side virtually ALWAYS tests as ready to write, thus even
passing in a timeout value as shown in the second call below:
```
isc_result_t omapi_one_dispatch (omapi_object_t *wo,
struct timeval *t)
{
:
/* poll once */
count = select(max + 1, &r, &w, &x, &now);
if (!count) {
/* We are dry now */
trigger_event(&rw_queue_empty);
/* Wait for a packet or a timeout... XXX */
r = rr;
w = ww;
x = xx;
count = select(max + 1, &r, &w, &x, t ? &to : NULL);
}
:
```
results in an immediate return from select. Thus we should only test the write side of the socket for readiness to write if we are connected AND we have data to write.4.4.3-beta1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/231final release of 4.4.32022-03-08T09:25:06ZWlodzimierz Wencelfinal release of 4.4.34.4.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/226docs/trivial: typo in dhcpd.conf.5 manpage2022-03-04T09:34:38ZJan "Yenya" Kasprzakdocs/trivial: typo in dhcpd.conf.5 manpageHello,
there is apparently a typo in dhcpd.conf.5 manpage:
"_The valid lifetime determines at what point **at** lease might be said to have expired_"
Patch attached:
[dhcpd.conf.5.diff](/uploads/fe4251426005e586c2ec3746c9860328/dhcpd...Hello,
there is apparently a typo in dhcpd.conf.5 manpage:
"_The valid lifetime determines at what point **at** lease might be said to have expired_"
Patch attached:
[dhcpd.conf.5.diff](/uploads/fe4251426005e586c2ec3746c9860328/dhcpd.conf.5.diff)
Thanks for considering this.4.4.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/223RFE dhcrelay: add option to force giaddr2022-03-04T14:04:05ZjelmdRFE dhcrelay: add option to force giaddr
**Problem**
Some buggy dhcp clients (e.g. Solaris grub, which gets used e.g. for network install) use the address of the dhcp gateway (the host on which dhcrelay is running) to setup its default route instead of the announced default r...
**Problem**
Some buggy dhcp clients (e.g. Solaris grub, which gets used e.g. for network install) use the address of the dhcp gateway (the host on which dhcrelay is running) to setup its default route instead of the announced default router (3) entry. Therefore it is not able to download the config/kernel/miniroot and network [emergency] boot does not work (unless the required server are in the same [V]LAN/subnet).
**Solution**
Add an option e.g. "-g <ip_address>" to force setting the gw address in packages sent back to the dhclient to the given <ip_address>.
**Alternatives**
None.
**Funding its development**
No funding is needed. We already developed a patch and use it for several years on our gpu cluster as well as department networks and can be considered stable. However, wondering how to submit it. Clone and add a PR or just attaching it as plain text?4.4.3Tomek MrugalskiTomek Mrugalskihttps://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/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/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/80New relay unit test code fails to link using libtool under Fedora 30/Centos 82020-01-21T19:13:05ZThomas MarkwalderNew relay unit test code fails to link using libtool under Fedora 30/Centos 8Build farm failed to build on Fedora30 (and Centos 8) when trying to link the new unit test binary, relay/tests/relay_unitttest:
```
libtool: link: gcc -g -O2 -I../../../../includes -I/home/jenkins/workspace/isc-dhcp-master-distcheck/L...Build farm failed to build on Fedora30 (and Centos 8) when trying to link the new unit test binary, relay/tests/relay_unitttest:
```
libtool: link: gcc -g -O2 -I../../../../includes -I/home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/include -o .libs/relay_unittests dhcrelay.o relay_unittests.o -L/opt/atf/lib /opt/atf/lib/libatf-c.a ../../common/.libs/libdhcp.so ../../omapip/.libs/libomapi.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/irs/.libs/libirs.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/isccfg/.libs/libisccfg.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/dns/.libs/libdns.so /home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/bind/bind-9.11.14/lib/isc/.libs/libisc.so -ldl -lcap -lz -Wl,-rpath -Wl,/home/jenkins/workspace/isc-dhcp-master-distcheck/LIBTOOL/True/label/fedora-64-latest/dhcp-4.4.2b1/_inst/lib
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `find_class'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `classify'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `dhcpv6'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `check_collection'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `bootp'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `dhcp'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `parse_allow_deny'
/usr/bin/ld: ../../common/.libs/libdhcp.so: undefined reference to `dhcp_set_control_state'
```
Need to add function definitions for these to the test code.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/75Add interface name to socket setup fatal error logs2020-01-14T19:31:54ZThomas MarkwalderAdd interface name to socket setup fatal error logsThere mulitple calls to setsockopt (and the ilk) in common/socket.c that do not emit the interface name for which the operation is being invoked. It's helpful data to have when these calls fail and while it can typically be inferred, it...There mulitple calls to setsockopt (and the ilk) in common/socket.c that do not emit the interface name for which the operation is being invoked. It's helpful data to have when these calls fail and while it can typically be inferred, it's easy enough to simply emit it.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/72(From ISC Bugs 47555) dhcpd: failover.c...:scrubbing lease for ... emitted un...2020-01-14T12:29:40ZCathy Almond(From ISC Bugs 47555) dhcpd: failover.c...:scrubbing lease for ... emitted unexpectedlyFrom [BUG ticket #47555](https://bugs.isc.org/Ticket/Display.html?id=47555) - I understand the intent was to fix this in 4.4.2 but it seems not to have had a GL issue opened for it.
Originally from Customer Support ticket [#12731](https...From [BUG ticket #47555](https://bugs.isc.org/Ticket/Display.html?id=47555) - I understand the intent was to fix this in 4.4.2 but it seems not to have had a GL issue opened for it.
Originally from Customer Support ticket [#12731](https://support.isc.org/Ticket/Display.html?id=12731)
This message is logged by scrub_lease() in server/failover.c:
void scrub_lease(struct lease* lease, const char *file, int line) {
log_debug ("%s(%d):scrubbing lease for %s, hostname: %s", file,
line,
--
It seems to be the only log_debug statement in the failover code that is not surrounded by a "#if defined (DEBUG_FAILOVER_MESSAGES)" statement, which seems to be an oversight.
The code that introduced this logging stanza was added to ISC DHCP with this change:
- Leases are now scrubbed of certain prior use information when pool
re-balancing reassigns them from one FO peer to the other. This
corrects an issue where leases that were offered but not used
by the client retained the client hostname from the original
client. Thanks to Pavel Polacek, Jan Evangelista Purkyne University
for reporting the issue.
[ISC-Bugs #42008]4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/71Correct buffer pointer logic in dhcrelay agent option functions2020-01-28T15:02:10ZThomas MarkwalderCorrect buffer pointer logic in dhcrelay agent option functionsTwo functions in dhcrelay.c, strip_relay_agent_options() and add_relay_agent_options() incorrectly advance pointers when removing existing agent options. See #63 for details.
This will need to be fixed in v4_1_esv as well.Two functions in dhcrelay.c, strip_relay_agent_options() and add_relay_agent_options() incorrectly advance pointers when removing existing agent options. See #63 for details.
This will need to be fixed in v4_1_esv as well.4.4.2Thomas MarkwalderThomas Markwalder