dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/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/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/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/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/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/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/13DHCP server segfaults when exceeding lease limit2019-07-17T14:25:54ZGhost UserDHCP server segfaults when exceeding lease limit---
name: DHCP Server segfaults when exceeding lease limit
about: debugging DHCP server
---
The dhcpd server dies with segmentation fault when exceeds the lease
limit in a class.
See the relevant information [in this ticket](https://...---
name: DHCP Server segfaults when exceeding lease limit
about: debugging DHCP server
---
The dhcpd server dies with segmentation fault when exceeds the lease
limit in a class.
See the relevant information [in this ticket](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782434) :
The bug is still exists in 4.4.1.
I've patched 4.4.1 with the old code and it is working now as expected on
production environments (~15k endpoints/server).
Patch:
```
--- isc-dhcp-4.4.1.orig/server/dhcp.c
+++ isc-dhcp-4.4.1/server/dhcp.c
@@ -2554,24 +2554,16 @@ void ack_lease (packet, lease, offer, wh
one, and if we do, try to do so. */
if (lease->billing_class == NULL) {
char *cname = "";
- int bill = 0;
+ int bill = 0;
+ for (i = 0; i < packet->class_count; i++) {
+ if (packet->classes[i]->lease_limit) {
+ bill++;
+ if (bill_class(lease,
+ packet->classes[i]))
+ break;
+ }
+ }
- for (i = 0; i < packet->class_count; i++) {
- struct class *billclass, *subclass;
-
- billclass = packet->classes[i];
- if (billclass->lease_limit) {
- bill++;
- if (bill_class(lease, billclass))
- break;
-
- subclass = billclass->superclass;
- if (subclass == NULL)
```
Please review my code.
I couldn't understand, what was the idea behind the new classes.
Thanks,
Peter4.4.2Thomas MarkwalderThomas Markwalderhttps://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/16A NSUPDATE compiling issue was observed2019-07-04T10:03:19ZGhost UserA NSUPDATE compiling issue was observedDescription:
A following error was observed:
```
| omapip/isclib.c: In function 'dns_client_init':
| omapip/isclib.c:356:18: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'dnsclient'
| if (dhcp_gbl_ctx.dnsclien...Description:
A following error was observed:
```
| omapip/isclib.c: In function 'dns_client_init':
| omapip/isclib.c:356:18: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'dnsclient'
| if (dhcp_gbl_ctx.dnsclient == NULL) {
| ^
| omapip/isclib.c:363:24: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'dnsclient'
| &dhcp_gbl_ctx.dnsclient,
| ^
| omapip/isclib.c:364:24: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'use_local4'
| (dhcp_gbl_ctx.use_local4 ?
| ^
| omapip/isclib.c:365:25: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'local4_sockaddr'
| &dhcp_gbl_ctx.local4_sockaddr
| ^
| omapip/isclib.c:367:24: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'use_local6'
| (dhcp_gbl_ctx.use_local6 ?
| ^
| omapip/isclib.c:368:25: error: 'dhcp_context_t {aka struct dhcp_context}' has no member named 'local6_sockaddr'
| &dhcp_gbl_ctx.local6_sockaddr
```
Test source is based on:
https://source.isc.org/git/dhcp.git
```
commit 85ef0d90e2ab5eee758242d5a094c1d12ce24576
Merge: a5b21e1 479b929
Author: Francis Dupont <fdupont@isc.org>
Date: Thu Nov 29 16:41:42 2018 +0100
Fixed server option code point conflict
```
How to reproduce:
Drop one line in includes/site.h:
```
-#define NSUPDATE
```
Possible fix:
I have verified it could be fixed by this patch: [0001-Fix-a-NSUPDATE-compiling-issue.patch](/uploads/6c1d137a5ee712338c7df0ca8a081a55/0001-Fix-a-NSUPDATE-compiling-issue.patch)
How to contact the reporter:
liu.ming50@gmail.com4.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/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/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/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/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/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/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/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 Markwalderhttps://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/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/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 Markwalder