dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2021-03-02T07:27:17Zhttps://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/4we need a contributing.md for ISC DHCP2021-03-02T07:27:17ZVicky Riskvicky@isc.orgwe need a contributing.md for ISC DHCPWe had some stuff about how to contribute on the web site, I think that content is mostly now here:
https://kb.isc.org/docs/contributing-to-iscs-open-source
it can be boilerplate. it should probably cover at least:
- how to submit a pat...We had some stuff about how to contribute on the web site, I think that content is mostly now here:
https://kb.isc.org/docs/contributing-to-iscs-open-source
it can be boilerplate. it should probably cover at least:
- how to submit a patch (presumably now via gitlab?)
- that your contribution will be covered by the current license for the project
- that you need to submit tests and doc for your contribution
- if there is still a contrib directory, what are the rules for what goes in there (e.g. ldap stuff?)https://gitlab.isc.org/isc-projects/dhcp/-/issues/2AFTR-Name appears to be wrongly encoded2021-03-02T07:27:16ZThomas MarkwalderAFTR-Name appears to be wrongly encodedReported by Bluecat under support ticket:
https://support.isc.org/Ticket/Display.html?id=14126
We have a non-compliance issue with a little-used option. Gave them a patch which changed format type to 'D', which is compliant with RFC 10...Reported by Bluecat under support ticket:
https://support.isc.org/Ticket/Display.html?id=14126
We have a non-compliance issue with a little-used option. Gave them a patch which changed format type to 'D', which is compliant with RFC 1035 formating. They replied that this works fine for them. We need to open an RT ticket and change it formally, along with the others that are currently 'd', as they are also wrong.
Simply change 'd' to 'D' common/tables.c as shown the patch below:
[14126_v441.patch](/uploads/0b4d8dd045542e80832af2be669aea37/14126_v441.patch)4.1-ESV-R16Francis DupontFrancis Duponthttps://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/116keama compilation on Fedora 32 fails2020-07-30T12:32:00ZMichal Nowikowskikeama compilation on Fedora 32 fails```
gcc -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/vagrant/bind/include -o keama keama.o data.o conflex.o json.o confparse.o parse.o options.o reduce.o print.o eval.o
/usr/bin/ld: conflex.o:/vagrant/keama/keama.h:...```
gcc -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/vagrant/bind/include -o keama keama.o data.o conflex.o json.o confparse.o parse.o options.o reduce.o print.o eval.o
/usr/bin/ld: conflex.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: conflex.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: json.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: json.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: confparse.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: confparse.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: parse.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: parse.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: options.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: options.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: reduce.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: reduce.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: print.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: print.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
/usr/bin/ld: eval.o:/vagrant/keama/keama.h:61: multiple definition of `parses'; keama.o:/vagrant/keama/keama.h:61: first defined here
/usr/bin/ld: eval.o:/vagrant/keama/keama.h:38: multiple definition of `resolve'; keama.o:/vagrant/keama/keama.h:38: first defined here
collect2: error: ld returned 1 exit status
```Francis DupontFrancis Duponthttps://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/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/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 Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/18Bundle BIND9 version-correct tar ball into the main repo2019-11-18T15:24:12ZThomas MarkwalderBundle BIND9 version-correct tar ball into the main repoThe BIND9 tarball, Makefile.in and version file were added dhcp/bind directory on the migration-assistant branch. This makes it possible to pull everything needed in just our repo and ensures you have correct version of bind9. It elimi...The BIND9 tarball, Makefile.in and version file were added dhcp/bind directory on the migration-assistant branch. This makes it possible to pull everything needed in just our repo and ensures you have correct version of bind9. It eliminates outsiders needing to run util/bind.sh. We need to follow suit and do this to main repo. Either that or we simply merge the migration-assistant branch into master.4.4.2https://gitlab.isc.org/isc-projects/dhcp/-/issues/34Merge Keama and distribute it2019-11-12T16:13:15ZThomas MarkwalderMerge Keama and distribute itKeama branch should be merged into master so that it can be distributed with 4.4.2 release.Keama branch should be merged into master so that it can be distributed with 4.4.2 release.4.4.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/15confpars.c has invalid error messages when memory allocation fails2019-11-08T17:40:56ZGhost Userconfpars.c has invalid error messages when memory allocation failsGCC 9 detects two cases where confpars.c includes NULL values in error messages. The error exists in both 4.4.1 and current master; I believe the attached patch is a correct fix for them.
[0001-Emit-correct-error-message-when-malloc-fai...GCC 9 detects two cases where confpars.c includes NULL values in error messages. The error exists in both 4.4.1 and current master; I believe the attached patch is a correct fix for them.
[0001-Emit-correct-error-message-when-malloc-fails.patch](/uploads/2422be5dd4cacd64ace575f694c4fd30/0001-Emit-correct-error-message-when-malloc-fails.patch)4.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/36ISC DHCPv6 server not receving incoming DHCPv6 client info request message2019-07-25T13:03:16ZGhost UserISC DHCPv6 server not receving incoming DHCPv6 client info request messageI am running ISC DHCPv6 server and odhcp6c client is sending DHCPv6 info request message. Using tcpdump, I am able to see the client messages in the server ethernet port. But server is not responding/receiving incoming info request (not ...I am running ISC DHCPv6 server and odhcp6c client is sending DHCPv6 info request message. Using tcpdump, I am able to see the client messages in the server ethernet port. But server is not responding/receiving incoming info request (not seeing any log messages for the incoming DHCPv6 info req message). The ISC DHCPv6 version is 4.4.1 in centos7. Looks like that I am seeing following bug reported here in the below URL. can you please confirm ?? if it is related to this below bug, how to resolve it in my ISC DHCP server 4.4.1 version ??
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882250
Thanks,
Rajaram.Thomas MarkwalderThomas Markwalder