ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-09-16T14:02:39Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/1Orphan guard records with ddns-dual-stack-mixed-mode enabled2023-09-16T14:02:39ZThomas MarkwalderOrphan guard records with ddns-dual-stack-mixed-mode enabledSubtle problem reported by Bluecat via support ticket:
https://support.isc.org/Ticket/Display.html?id=14222
They found a scenario where dual-stack mode does not work correctly. When both ddns-guard-id-must-match and ddns-other-guard-i...Subtle problem reported by Bluecat via support ticket:
https://support.isc.org/Ticket/Display.html?id=14222
They found a scenario where dual-stack mode does not work correctly. When both ddns-guard-id-must-match and ddns-other-guard-is-dynamic are enabled, the server does not correctly distinguish between no guard record present and guard record present but does not match the client, when a guard record of the other type is present.
This causes the server to decide a v4 A record with a TXT guard record for a different client, is actually a static entry because the same hostname has a v6 DHCID record. It then precedes to replace the A/PTR records and adds another v4 TXT record for the new client.
What it should have done is recognized the presence of a none-matchingTXT record, and not do the updates.
I created a patch (attached) for them that corrects this be adding the necessaryDNS pre-requisite when both of those knobs are true:
[14222_v441.patch](/uploads/52b15daea4c57f6337535cde5293b3c7/14222_v441.patch)4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/68Changing 'd' content type to RFC 1035 name broke omapi-key parsing2023-05-17T11:22:29ZThomas MarkwalderChanging 'd' content type to RFC 1035 name broke omapi-key parsingWe overlooked three server options with 'd' format: omapi-key, ldap-port, ldap-init-retry. Changing 'd' under #2 from being handled as text, breaks the ability to match omapi-key to any parsed keys. When server config file defines a TS...We overlooked three server options with 'd' format: omapi-key, ldap-port, ldap-init-retry. Changing 'd' under #2 from being handled as text, breaks the ability to match omapi-key to any parsed keys. When server config file defines a TSIG key to use with omapi such as shown below:
```
# define a key
key toms-key {
algorithm hmac-md5;
secret <some key here>;
}
# tell the server to use the key for omapi
omapi-key toms-key;
```
With a "d" option format for omapi-key, during configuration parsing the server will emit the error "OMAPI key : not found" and then exit. This is because the value for omapi-key option when evaluated by the server is in RFC 1035 format "\007toms-key" rather than plain text "toms-key". Changing the format to "t" will solve the problem. This should work for all three as prior #2, "d" format content equivalent to plain text.
This will need to go to v4_1_esv too.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/10Make ping-check timeout configurable in ms, thus allowing timeouts < 1s2022-03-31T19:49:23ZCathy AlmondMake ping-check timeout configurable in ms, thus allowing timeouts < 1s---
name: Make ping-check timeout configurable in ms
about: Currently ping-check can be specified only in seconds, with a minimum value of 1s. For some situations it might be desirable to make this even shorter.
---
As reported in Sup...---
name: Make ping-check timeout configurable in ms
about: Currently ping-check can be specified only in seconds, with a minimum value of 1s. For some situations it might be desirable to make this even shorter.
---
As reported in Support ticket [#14375](https://support.isc.org/Ticket/Display.html?id=14375).
The scenario is a problem with a UEFI DHCP process which appears to timeout around 600ms, due to a Bitlocker Network Unlock process. When the ping before allocate check is enabled on the DHCP server, the minimum timeout being 1 second, this results on the DHCP process on the client failing before the ping timeout is reached.
This makes using Bitlocker Network Unlock impossible to deploy on a network that is using ISC DHCP with ping-check enabled.
Is it possible to permit more granularity within the ping timeout value?
This might also benefit other environments using devices with embedded DHCP clients that don't perform their own client-based local checks for duplication before accepting a lease offer.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/7Improve error message "mdb.c(319): non-null pointer"2021-03-02T07:27:17ZCathy AlmondImprove error message "mdb.c(319): non-null pointer"Per Support ticket [RT #14122](https://support.isc.org/Ticket/Display.html?id=14122)
In a dhcpd.conf that contains both client identifier AND uid in the
same host declaration, the following warning message is emitted as dhcpd starts:
`...Per Support ticket [RT #14122](https://support.isc.org/Ticket/Display.html?id=14122)
In a dhcpd.conf that contains both client identifier AND uid in the
same host declaration, the following warning message is emitted as dhcpd starts:
`mdb.c(319): non-null pointer`
Having both is ambiguous and not supported - but the error message is not in the least helpful or useful for diagnosing what is wrong.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/5Delete build instructions for NextStep and other obsolete systems2021-03-02T07:27:17ZVicky Riskvicky@isc.orgDelete build instructions for NextStep and other obsolete systemsI know this is a nit, but it bugs me to see NextStep and Ultrix and so on in the readme. If it is ok with you Thomas, let me know and I will delete the offending bits.
(Ideally, we would also add a platforms.md and list the platforms we ...I know this is a nit, but it bugs me to see NextStep and Ultrix and so on in the readme. If it is ok with you Thomas, let me know and I will delete the offending bits.
(Ideally, we would also add a platforms.md and list the platforms we test on and know it works on there.)4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/3Migrate RT #48575: Avoid python dependency in bind9 build2021-03-02T07:27:16ZThomas MarkwalderMigrate RT #48575: Avoid python dependency in bind9 buildBIND9 changed the default configure behavior to require python. This issue was opened to turn switch this off. It was addressed and reviewed in RT but never merged.BIND9 changed the default configure behavior to require python. This issue was opened to turn switch this off. It was addressed and reviewed in RT but never merged.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/26ieee.org oui.txt URL moved2021-01-18T17:49:11ZTommy Smithieee.org oui.txt URL moved---
name: Bug report - ieee.org oui.txt URL moved
about: The location of the oui.txt file has been moved on the ieee.org website to a new URL.
---
**Describe the bug**
The URL for the oui.txt file on ieee.org has changed.
To get manufac...---
name: Bug report - ieee.org oui.txt URL moved
about: The location of the oui.txt file has been moved on the ieee.org website to a new URL.
---
**Describe the bug**
The URL for the oui.txt file on ieee.org has changed.
To get manufacturer names please download http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt
**To Reproduce**
Steps to reproduce the behavior:
1. Remove /usr/local/etc/oui.txt
2. Run dhcp-lease-list
3. See message to "To get manufacturer names please download http://standards.ieee.org/regauth/oui/oui.txt to /usr/local/etc/oui.txt"
4. Attempt to download http://standards.ieee.org/regauth/oui/oui.txt
5. Get 404 error from ieee.org
**Expected behavior**
Message from dhcp-list-list should be as follows:
To get manufacturer names please download http://standards-oui.ieee.org/oui.txt to /usr/local/etc/oui.txt
**Environment:**
- ISC DHCP version: 4.3.5 to current
- OS: e.g. Ubuntu 18.04 x64
**Additional Information**
I have a patch ready to go that updates /contrib/dhcp-lease-list.pl with the correct URL.
I need to have permissions to push the branch and then make the merge request.
**Describe the solution you'd like**
I would like permission to push a branch and then submit a merge request with the fix.
**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? No.
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code? Yes.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them. Yes4.4.2https://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 Markwalderhttps://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/57Fix reference count leaks2020-01-14T08:15:10ZThomas MarkwalderFix reference count leaksFix leaks reported in #44.Fix leaks reported in #44.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/37Understanding 'authoritative' in dhcpd.conf2019-12-20T16:26:21ZCathy AlmondUnderstanding 'authoritative' in dhcpd.confFrom Support ticket [#14997](https://support.isc.org/Ticket/Display.html?id=14997)
We were surprised that when an ISC DHCP server does not have 'authoritative' set to yes an option (the default is no) that all DHCPINFORM messages are no...From Support ticket [#14997](https://support.isc.org/Ticket/Display.html?id=14997)
We were surprised that when an ISC DHCP server does not have 'authoritative' set to yes an option (the default is no) that all DHCPINFORM messages are not responded to and the logs contain "not authoritative for subnet".
Reading the man page for dhcpd.conf, we see this explanation:
> The authoritative statement
...
> The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.
In other words, if there are clients out there that are going to be getting leases from other servers that ISC DHCP knows nothing about, and then trying to get additional options via DHCPINFORM, and you're not really sure that you've got your configuration correct, then *not* being authoritative is probably the right way to go...
> Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.
In other words, if you're certain that you're right and any clients sending DHCP messages to your servers for addresses that they shouldn't be, then being authoritative is correct.
=======
But not having your ISC DHCP server be authoritative, causes it not to respond to *any* DHCPINFORMs, rather than just those with which it has a problem. It stops the DHCPNAKs, but it also stops the DHCPACKs too.
=======
Is this something where the documentation could be cleared, or is it functionality that was not supposed to be this way?4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/35Update instructions for getting and building ATF for unit tests2019-12-02T20:23:12ZThomas MarkwalderUpdate instructions for getting and building ATF for unit testsDocumentation for getting and building ATF for unit testing needs to be updated, since Kyua's project site has changed.Documentation for getting and building ATF for unit testing needs to be updated, since Kyua's project site has changed.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/19HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined2019-11-22T11:13:17ZJoe LeVequeHAVE_SO_BINDTODEVICE referenced before it has a chance to be defined---
name: HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined
---
**Describe the bug**
In includes/osdep.h, `HAVE_SO_BINDTODEVICE` is referenced on [line 152](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includ...---
name: HAVE_SO_BINDTODEVICE referenced before it has a chance to be defined
---
**Describe the bug**
In includes/osdep.h, `HAVE_SO_BINDTODEVICE` is referenced on [line 152](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includes/osdep.h#L152) in the following conditional:
```
#if defined (USE_BPF_SEND) || defined (USE_NIT_SEND) || \
defined (USE_DLPI_SEND) || defined (USE_UPF_SEND) || \
defined (USE_LPF_SEND) || \
(defined (USE_SOCKET_SEND) && defined (HAVE_SO_BINDTODEVICE))
# define USE_SOCKET_FALLBACK
# define USE_FALLBACK
#endif
```
However, it might not get defined until [line 267](https://gitlab.isc.org/isc-projects/dhcp/blob/master/includes/osdep.h#L267), as follows:
```
#if defined (SO_BINDTODEVICE) && !defined (HAVE_SO_BINDTODEVICE)
# define HAVE_SO_BINDTODEVICE
#endif
```
Therefore, if `USE_SOCKET_SEND` is defined, it is possible that `USE_SOCKET_FALLBACK` and `USE_FALLBACK` will not get defined, even though they should, simply because `HAVE_SO_BINDTODEVICE` is referenced before it has had a chance to get defined.
**To Reproduce**
Steps to reproduce the behavior:
1. Add a `#pragma message()` line inside the first `#if` block mentioned above (e.g., at line 153 of includes/osdep.h) so that the preprocessor will print the message if it enters the block
2. Compile isc-dhcp on a system which defines `SO_BINDTODEVICE` (e.g., Debian Stretch), while also defining `USE_SOCKETS` (e.g., via the `--enable-use-sockets` configure flag)
3. Note that the message does not print, although it should
**Expected behavior**
`HAVE_SO_BINDTODEVICE` should have an opportunity to be defined before it is referenced
**Environment:**
- ISC DHCP version: All versions since commit d758ad8cac9c00c70cfe4dd459bf7e87c268c579 (pre-version 4.0.0)
- OS: Debian Jessie/Stretch, most likely many other Linux flavors
- Which features were compiled in: `USE_SOCKETS`
**Describe the solution you'd like**
Reorder the file includes/osdep.h to ensure `HAVE_SO_BINDTODEVICE` has a chance to be defined before it is referenced.4.4.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/53dhclient v4.4.1 - REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT2019-11-18T16:52:56ZGhost Userdhclient v4.4.1 - REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT---
name: REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT
about: dhclient v4.4.1
---
**Describe the bug**
We noticed that sometimes, under heavy load, when SIGTERM/SIGINT is sent to dhclient, the following ASSERT is trig...---
name: REQUIRE(ctx->running) assertion triggered on SIGTERM/SIGINT
about: dhclient v4.4.1
---
**Describe the bug**
We noticed that sometimes, under heavy load, when SIGTERM/SIGINT is sent to dhclient, the following ASSERT is triggered:
```
...lib/isc/unix/app.c:574: REQUIRE(ctx->running) failed, back trace
#0 0x59355e in ??
#1 0x5936ea in ??
#2 0x5b4492 in ??
#3 0x7f20d70f0560 in ??
#4 0x7f20d71758f0 in ??
#5 0x7f20d71757a4 in ??
#6 0x42486c in ??
#7 0x40a39a in ??
#8 0x7f20d70dd6b0 in ??
#9 0x40ae39 in ??
Aborted
```
If the SIGTERM/SIGINT signal is sent during startup, in the small window interval between signal handler registration and the moment when ctx->running is set to 1, the REQUIRE(ctx->running) assertion is triggered.
Please let us know if any additional info is required.4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/9DHClient: static lease not assigned with no DHCP Server responding (No DHCPOF...2019-11-18T16:38:29ZGhost UserDHClient: static lease not assigned with no DHCP Server responding (No DHCPOFFERS received.)---
name: DHC Client: Access all dynamic and static leases on signal
about: debugging DHC client
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? YES
- Are you sure ...---
name: DHC Client: Access all dynamic and static leases on signal
about: debugging DHC client
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? YES
- Are you sure your feature is not already implemented in the latest Kea version? YES - this is a Client issue.
- Are you sure what you would like to do is not possible using some other mechanisms?
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? unk
**Is your feature request related to a problem? Please describe.**
Was trying to troubleshoot an issue:
In principle: dhclient does not use the static leases as of
current (and for a couple of versions) if all dynamic leases have expired
because of a programming bug in dhclient.c, routine state_panic in line 2331:
loop needs to be set to 0/NUL here, otherwise with no dynamic leases around
the variable loop is already dhclient->active when reaching line 2403 (after
jumping to activate_next), hence that static lease never gets into the while
loop and never gets activated, instead the "no leases in persistent database
- sleeping" message arrives, dhclient removes the IP and kills the network.
We currently experience such a problem where a DHCP server (by a router of an
ISP) does not respond for hours (for unknown reasons) causing havoc in the
network (which otherwise would work).
I have for now recompiled my own version with that bug fix in place which
works well now.
**Describe the solution you'd like**
I'd like to file a feature request to be able to see the internal
leases database (including dynamic and static leases with all details) upon a
signal (e.g. kill -USR1 pid of dhclient), this would be extremely useful for
such debugging purposes. So far I assumed the entry in the dhclient.conf
wasn't valid/erroneous and therefore rejected somehow.
**Describe alternatives you've considered**
**Additional context**
**Funding its development**
**Participating in development**
**Contacting you**
(request entered on behalf of the user, who had trouble setting up a valid account on Gitlab)4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/50Update Contributor's Guide to reflect gitlab and new procedures2019-11-18T16:31:10ZThomas MarkwalderUpdate Contributor's Guide to reflect gitlab and new proceduresCONTRIBUTING.md is seriously out of data and also visible on the Wiki. It needs to be revamped to reflect gitlab. See Kea's CONTRIBUTING.md.CONTRIBUTING.md is seriously out of data and also visible on the Wiki. It needs to be revamped to reflect gitlab. See Kea's CONTRIBUTING.md.4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/33Fix dhcpd/dhcrelay in v6 mode operation on OpenBSD2019-11-18T16:18:43ZBrad SmithFix dhcpd/dhcrelay in v6 mode operation on OpenBSDThe linked diff has been in our tree for quite awhile. It fixes v6 mode operation of dhcpd/dhcrelay on OpenBSD.
sin6_scope_id needs to be set not just for dhclient but also for dhcpd/dhcrelay.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~c...The linked diff has been in our tree for quite awhile. It fixes v6 mode operation of dhcpd/dhcrelay on OpenBSD.
sin6_scope_id needs to be set not just for dhclient but also for dhcpd/dhcrelay.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/isc-dhcp/patches/patch-common_socket_c?rev=1.7&content-type=text/plain&hideattic=14.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/30Coverity: memory leaks in conf file parsing2019-11-18T16:01:03ZMark AndrewsCoverity: memory leaks in conf file parsingCIDs 1448191, 1448193, 1448194, 1448195CIDs 1448191, 1448193, 1448194, 14481954.4.2Thomas MarkwalderThomas Markwalder