ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-11-02T15:10:41Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1945Rebalance debug logging2022-11-02T15:10:41ZTomek MrugalskiRebalance debug loggingWe do have a serious mess with the debug messages. This is a topic that has been signaled on several occasions, with people asking and getting confused in general. Here's a couple pointers:
- see #1916 for specific customer complaint
- ...We do have a serious mess with the debug messages. This is a topic that has been signaled on several occasions, with people asking and getting confused in general. Here's a couple pointers:
- see #1916 for specific customer complaint
- packet drops used to be logged on many levels
- we currently use levels 0, 10, 15, (no 20 or 30), 40, 45, 50 and 55
- the documentation incorrectly states that the debuglevel goes to 99 (the actual value configured can be larger, the highest value we use is 55)
- it is impossible for the user to figure out a logging level of a given message, even if looking at the code. The level constants are defined in .h file, but defined in .cc, then in many cases not used directly, but used to set up other const values that are used. This is not a programming logic an average sysadmin is willing to follow.
- there should be an ability to log the debuglevel similar to loglevel in the logs.
- there should be a way to update the messages doc with the actual debug levels being used. Some sort of a maintenance script could do that. We have `tools/reorder_message_file.py`. Perhaps we could extend it to do something extra for us?
- DBGLVL_COMMAND_DATA (20) is defined, but not used anywhere
- no debug level is defined for 30
This is definitely post 2.0 topic.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1943make Kea link statically with external libraries2022-11-02T15:10:41ZGreg Rabilmake Kea link statically with external librariesIn an attempt to build static Kea binaries, I have set the following configure flags:
--disable-shared
--enable-static-link
However, these settings don't appear to do anything, as shared libraries are created and the binary programs (e...In an attempt to build static Kea binaries, I have set the following configure flags:
--disable-shared
--enable-static-link
However, these settings don't appear to do anything, as shared libraries are created and the binary programs (e.g. kea-dhcp4) are not statically linked. Are these flags expected to work in Kea 1.8.2?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1942Refactor ClientClassDictionary to provide indexing2022-11-02T15:10:41ZMarcin SiodelskiRefactor ClientClassDictionary to provide indexingI would like to propose refactoring the `ClientClassDictionary` internals to support indexing classes by various parameters. Right now we index by class names and we have an ordered index. In #1836 we are adding a change which matches cl...I would like to propose refactoring the `ClientClassDictionary` internals to support indexing classes by various parameters. Right now we index by class names and we have an ordered index. In #1836 we are adding a change which matches classes with configured server identifiers. Without indexing, such matching is sub-optimal. Perhaps, if we migrate the class collection to multi index container we could easily add additional indexing if necessary.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1939Kea 1.8.2 configure fails when linking to static OpenSSL library2022-11-02T15:10:41ZGreg RabilKea 1.8.2 configure fails when linking to static OpenSSL libraryI am attempting to build a static Kea 1.8.2 binary on CentOS7. I have built a static version of OpenSSL 1.1.1k (./config no-shared). When running configure for Kea 1.8.2 and specifying the --with-openssl directive, it fails with the fo...I am attempting to build a static Kea 1.8.2 binary on CentOS7. I have built a static version of OpenSSL 1.1.1k (./config no-shared). When running configure for Kea 1.8.2 and specifying the --with-openssl directive, it fails with the following:
```
checking OS type... Linux
checking for sa_len in struct sockaddr... no
checking for usuable C++11 regex... no
checking for OpenSSL library... yes
checking OpenSSL version... OpenSSL 1.1.1k 25 Mar 2021
checking support of SHA-2... configure: error: missing EVP entry for SHA-2
```
Attached is the config.log file. [config.log](/uploads/68a099b66729e0f428375ce2fd77a95c/config.log)
As a work around, I am able to force it to configure properly by specifying LDFLAGS and LIBS:
`LDFLAGS="-L/opt/tmp/install/openssl/lib" LIBS="-lcrypto -lpthread"`
Note that this problem does not occur if OpenSSL is built with dynamic libraries.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1938prevent "(no branch, rebasing <branch>)" in the git commit message caused by ...2022-11-02T15:10:18ZAndrei Pavelandrei@isc.orgprevent "(no branch, rebasing <branch>)" in the git commit message caused by prepare-commit-msg```
git rebase <branch> # usually master or origin/master
# git stops on conflict
# conflict is resolved
git add <resolved_file>
git commit # <----- this right here is what is causing it
git rebase --continue
``````
git rebase <branch> # usually master or origin/master
# git stops on conflict
# conflict is resolved
git add <resolved_file>
git commit # <----- this right here is what is causing it
git rebase --continue
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1929`LibDHCP::packOptions4` code is incomplete2022-11-02T15:10:19ZFrancis Dupont`LibDHCP::packOptions4` code is incompleteMissing some `if (top)` or `if (!top)` in the code. Perhaps related to a report about duplicate options.Missing some `if (top)` or `if (!top)` in the code. Perhaps related to a report about duplicate options.backloghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/196dhcp6.unicast option not sent from server to client2021-06-11T06:39:29ZRevathy Sankarrdhcp6.unicast option not sent from server to clientisc dhcp version - 4.4.1
When "option dhcp6.unicast 3001::2" is added in DHCP Server conf file, we are seeing unicast option not beign sent in packet.
We had added the above option in global level as well in subnet level. Still this is ...isc dhcp version - 4.4.1
When "option dhcp6.unicast 3001::2" is added in DHCP Server conf file, we are seeing unicast option not beign sent in packet.
We had added the above option in global level as well in subnet level. Still this is not beign sent to Client.
In Client code , we lookup for DHCP6 option in server packet. Since its not present, client is not able to send unicast packet.
Pls help us solve this issue.
Thanks & Regards,
Revathy Shttps://gitlab.isc.org/isc-projects/bind9/-/issues/2766Implement TCP fallback on no cookie2023-11-02T16:21:21ZMark AndrewsImplement TCP fallback on no cookieFallback to TCP on no COOKIE has been flagged as a future extension for a while.
Implement this.
Default to `true` with the ability to disable via named.conf.Fallback to TCP on no COOKIE has been flagged as a future extension for a while.
Implement this.
Default to `true` with the ability to disable via named.conf.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2761Excessive interval between zone transfer retries after failure2021-06-09T18:02:44ZEverett FultonExcessive interval between zone transfer retries after failureFrom https://support.isc.org/Ticket/Display.html?id=18577
A customer using 9.11.30-S1 reports intermittent zone transfers with "failed setting up socket: address in use" being logged. This would not be a serious issue, except that more...From https://support.isc.org/Ticket/Display.html?id=18577
A customer using 9.11.30-S1 reports intermittent zone transfers with "failed setting up socket: address in use" being logged. This would not be a serious issue, except that more than 10 minutes can pass before a retry.https://gitlab.isc.org/isc-projects/kea/-/issues/1919ZTP with KEA for Huawei switches2021-07-29T14:50:36ZBranka AndrijasevicZTP with KEA for Huawei switchesHi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.hu...Hi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.huawei.com/enterprise/en/doc/EDOC0100533703?section=j004) the Switch Firmware is relying on the overlapping Options 141 + 146 (see https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#id2) which are conflicting in terms of DHCP Option Type.
We would therefore kindly ask ISC to review this issue, as it’s entirely blocking the introduction of ZTP / Autoconfiguration of Huawei Switches within our installation base.
In case no solution exists out of the box, we would further ask ISC to consider a compatibility option for allowing the override of standard RFC-ed options, see e.g. https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#kea-dhcpv4-compatibility-configuration-parameters
Kind Regardsoutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/195isc-dhcp-server fails to start after update2022-01-20T15:35:06ZxJustmy2centsisc-dhcp-server fails to start after update---
name: Bug report
about: DHCP Server fails to control subservices after upgrade
---
**Describe the bug**
**log from apt upgrade:**
```
Setting up isc-dhcp-server (4.3.5-3+deb9u2) ...
Job for isc-dhcp-server.service failed because ...---
name: Bug report
about: DHCP Server fails to control subservices after upgrade
---
**Describe the bug**
**log from apt upgrade:**
```
Setting up isc-dhcp-server (4.3.5-3+deb9u2) ...
Job for isc-dhcp-server.service failed because the control process exited with error code.
See "systemctl status isc-dhcp-server.service" and "journalctl -xe" for details.
invoke-rc.d: initscript isc-dhcp-server, action "start" failed.
* isc-dhcp-server.service - LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-06-06 10:34:25 CEST; 82ms ago
Docs: man:systemd-sysv-generator(8)
Process: 20278 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/isc-dhcp-server.service
`-1457 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
Jun 06 10:34:24 derdapp003 systemd[1]: Starting LSB: DHCP server...
Jun 06 10:34:24 derdapp003 isc-dhcp-server[20278]: Launching both IPv4 and IPv6 servers (please configure INTERFACES in /etc/default/isc-dhcp-serve…he other).
Jun 06 10:34:25 derdapp003 isc-dhcp-server[20278]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid curr….. failed!
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Jun 06 10:34:25 derdapp003 systemd[1]: Failed to start LSB: DHCP server.
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
```
```
root@derdapp003:~# ps -ef|grep dhcp
root 1457 1 0 Apr20 ? 00:03:24 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
root 20508 19428 0 10:37 pts/0 00:00:00 grep dhcp
```
**Cause**:
I have only IPv4 configured and up and running. On the upgrade isc seems to want IPv6 to be configured and fails with unspecific reason "exit-code".
First issue: the subprocess for dhcpd ipv4 is not stopped or not stopped in a correct manner.
Killing it manualy results in a pid file remaining, that also needs to be removed:
```
Jun 6 10:45:50 localhost isc-dhcp-server[20975]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists) ... failed!
Jun 6 10:45:50 localhost systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Jun 6 10:45:50 localhost systemd[1]: Failed to start LSB: DHCP server.
```
Even doing so, the ics-dhcp-server fails on the next start with the same error in sequence.
After configuring `nano /etc/default/isc-dhcp-server`
with
```
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACESv4="eth0.200 eth0.300 eth0.400"
INTERFACESv6=""
```
the server starts w/o any errors.
**claims**:
1. if no ipv6 interface is configured, the server should not fail to start, but just drop the ipv6 sequence
2. if the ics-dhcp-server fails to start for any reason, it should take care about subprocesses to be stopped in a correct way not leaving ghosts or pidfiles.
**Systeminformation**:
```
Linux derdapp003 4.19.59-sunxi #5.91 SMP Mon Jul 15 14:09:32 CEST 2019 armv7l GNU/Linux
description: ARMv7 Processor rev 4 (v7l)
product: LeMaker Banana Pro
~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.13 (stretch)
Release: 9.13
Codename: stretch
~# dpkg -l|grep dhcp
ii isc-dhcp-client 4.3.5-3+deb9u2 armhf DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.5-3+deb9u2 armhf common manpages relevant to all of the isc-dhcp packages
ii isc-dhcp-server 4.3.5-3+deb9u2 armhf ISC DHCP server for automatic IP address assignment
```https://gitlab.isc.org/isc-projects/kea/-/issues/1914HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading sometimes fails2023-02-27T13:41:09ZAndrei Pavelandrei@isc.orgHAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading sometimes failsThis time it happened on distcheck on CentOS 8.
https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/415/execution/node/136/log/?consoleFull
```
16:04:40 [ RUN ] HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading
16:04:...This time it happened on distcheck on CentOS 8.
https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/415/execution/node/136/log/?consoleFull
```
16:04:40 [ RUN ] HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading
16:04:40 ../../../../../../../src/hooks/dhcp/high_availability/tests/ha_service_unittest.cc:1096: Failure
16:04:40 Expected equality of these values:
16:04:40 2
16:04:40 factory3_->getResponseCreator()->getReceivedRequests().size()
16:04:40 Which is: 1
16:04:40 ../../../../../../../src/hooks/dhcp/high_availability/tests/ha_service_unittest.cc:1102: Failure
16:04:40 Value of: update_request3
16:04:40 Actual: false
16:04:40 Expected: true
16:04:40 [ FAILED ] HAServiceTest.sendSuccessfulUpdatesAuthorizedMultiThreading (2 ms)
```backloghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/194resolvconf support is missing in dhclient2022-03-09T19:00:02Zonehalf3544resolvconf support is missing in dhclientBy default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/...By default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/openvpn, which set up DNS servers from the private network). The natural solution is the usage of resolvconf, which manages such updates from multiple sources and merges them into /etc/resolv.conf
Since this is more like a feature request, it was suggested that this should be fixed here (https://bbs.archlinux.org/viewtopic.php?pid=1969134).
Would such PR be accepted? The changes are quite trivial..
Thanks.
**Describe the bug**
dhclient overwrites the /etc/resolv.conf blindly, disregarding the fact that it could have been updated by other (dhcp) clients
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient with default config
2. Modify /etc/resolv.conf by any means
3. Wait for the lease renewal on the dhclient interface
4. Observe the contents of the /etc/resolv.conf
**Expected behavior**
/etc/resolv.conf contents should be preserved somehow. Proposed way is to use resolvconf for that.
**Environment:**
dhclient --version
isc-dhclient-4.4.2
- OS: ArchLinux
Linux laptop_name 5.12.7-arch1-1 #1 SMP PREEMPT Wed, 26 May 2021 22:03:57 +0000 x86_64 GNU/Linux
pacman -F dhclient
core/netctl 1.24-1
usr/lib/netctl/dhcp/dhclient
**Additional Information**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
It is not - https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L80
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
Did not check, but would prefer to keep original dhclient
- Are you sure what you would like to do is not possible using some other mechanisms?
Using hooks, yes, but feature implementation is better to be done as close to the source as possible
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
arch linux forum - https://bbs.archlinux.org/viewtopic.php?pid=1969134#p1969134
**Is your feature request related to a problem? Please describe.**
I'm frustrated when my VPN tunnel DNS server IP is overwritten with the ISP dhcp
**Describe the solution you'd like**
Check if /usr/bin/resolvconf exists and use it if it does
**Describe alternatives you've considered**
switch to a different dhcp client
**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?
I could provide the patch once I can fork the project here
**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.
onehalf3544@gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/556Attempt to reduce Stork dependencies2023-12-11T10:00:07ZTomek MrugalskiAttempt to reduce Stork dependenciesThe recent security audit shows that we have lots of dependencies and that means more exposure to third party vulnerabilities and potential necessity to do frequent Stork security updates. That is something we clearly want to avoid.
@on...The recent security audit shows that we have lots of dependencies and that means more exposure to third party vulnerabilities and potential necessity to do frequent Stork security updates. That is something we clearly want to avoid.
@ondrej mentioned two tools that may possibly be helpful:
- https://dependencytrack.org/
- https://github.com/oss-review-toolkit/ort
I'm sure there are others. We should look at them and see if there's anything we don't need in our dependencies. This tickets covers just doing the analysis and assess how much effort would it be to do the dependency removal, if it is even feasible. The actual removal is out of scope.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1912update lib dns++ python tools2021-06-03T15:37:03ZFrancis Dupontupdate lib dns++ python tools#1880 showed that even they still work the python tools used for the dns++ library should be updated:
- src/lib/dns/gen-rdatacode.py complains about a not existing (BTW for a long time) file in a not existing (this point triggers the er...#1880 showed that even they still work the python tools used for the dns++ library should be updated:
- src/lib/dns/gen-rdatacode.py complains about a not existing (BTW for a long time) file in a not existing (this point triggers the error) src/lib/dns/python directory. IMHO the corresponding code is obsolete i.e. implements a feature which has not been used since a lot of years if it was used one day...
- src/lib/util/python/gen_wiredata.py triggers a warning with python3. I added a comment at the corresponding line of code.
The documentation should be updated too: for the first script it is in the s-rdatacode entry of the Makefile. The second is in a commented entry of the src/lib/dns/tests/testdata Makefile and requires to be called in the UTC timezone when timestamps are generated as for RRSIG or TKEY RRs (I used with success the TZ environment variable).outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/193DHCP Relay: replay from server is not forwarded (discarded ?)2022-03-09T19:13:59ZOlegDHCP Relay: replay from server is not forwarded (discarded ?)Hello, I have simple configuration of client-relay-server (by ISC):
1. client - 1 iface in net1 (10.0.0.0/24)
2. relay - 1 iface on net1 and 1 iface on net2 (10.0.10.0/24)
3. server - 1 iface on net2 (10.0.10.0/24).
When running...Hello, I have simple configuration of client-relay-server (by ISC):
1. client - 1 iface in net1 (10.0.0.0/24)
2. relay - 1 iface on net1 and 1 iface on net2 (10.0.10.0/24)
3. server - 1 iface on net2 (10.0.10.0/24).
When running it on **Linux Kernel 4.x.y **: all okey, request and replay are forwarded to/from server and IP address have been assigned to client.
When running on **Linux kernel 5.4.117 **: replay from server is lost somewhere in relay host or relay do not see it.
**Information about Relay**
My command line to run relay: _/usr/sbin/dhcrelay -d -pf /var/run/dhcrelay.pid -id eth3 -iu eth4 -c 10 -a 10.0.10.254_
Ip address of eth3 (to client) of relay is 10.0.0.1/24 and eth4 (to server) of relay is 10.0.10.1/24
**Information about Server**
Ip address of eth0 of server is 10.0.10.254/24
My command line to run dhcp server:_ /usr/sbin/dhcpd -user dhcpd -group dhcpd -cf /etc/dhcpd.conf eth0_
My config of dhcp server concerning to networks and ranges:
```
shared-network net-eth0 {
subnet 10.0.10.0 netmask 255.255.255.0 {
}
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.20;
}
}
```
I've used **tcpdump** on relay iface that looks to server and here is log:
1) Here is Request: 10.0.10.1 - is relay net2 iface of relay, 10.0.10.254 - is server net2 iface of server
`15:23:24.224319 08:00:27:eb:f2:44 > 08:00:27:2e:19:cd, ethertype IPv4 (0x0800), length 371: 10.0.10.1.67 > 10.0.10.254.67: BOOTP/DHCP, Request from 08:00:27:ef:1a:e9, length 329`
2) Here is Reply: 10.0.0.1 - is net1 iface of relay
`15:23:24.224778 08:00:27:2e:19:cd > 08:00:27:eb:f2:44, ethertype IPv4 (0x0800), length 342: 10.0.10.254.67 > 10.0.0.1.67: BOOTP/DHCP, Reply, length 300`
I've debugged also relay, and found, that when Replay needs to be received it was read be falback_discard() routine and relay can not see it. Here is debug of relay with some of my own debug-strings (comments starts with //):
```
//Initialization of relay staff
......
IPv4: Sending on Socket/fallback
//Here is omapi_iscsock_cb() called to read request
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
//before calling reader()
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343cc5e90 //address of reader (function got_one() )
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
IPv4: omapi_iscsock_cb: af reader(): status=0 --status of reading Request
//Here is when and where replay should be read but it is discarded
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
//before calling reader()
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343ce6a70 //address of reader (function fallback_discard() )
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343ce6a70 //address of reader (function fallback_discard() )
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
//Here is 2nd Request try
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343cc5e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
```
**For comparison with GOOD case**: this is log of relay:
```
IPv4: Sending on Socket/fallback
IPv4: disc_ifaces: in fallback_iface: setting fcntl
//Getting Request
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebb9e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebdaab0
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
**//Here is REPLAY**
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebb9e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=300
IPv4: do_relay4
IPv4: Forwarded BOOTREPLY for 08:00:27:ef:1a:e9 to 255.255.255.255
```
Tcpdump for good case:
```
//here is dump of eth4(to server) iface
18:17:39.866071 08:00:27:eb:f2:44 > 08:00:27:2e:19:cd, ethertype IPv4 (0x0800), length 371: 10.0.10.1.67 > 10.0.10.254.67: BOOTP/DHCP, Request from 08:00:27:ef:1a:e9, length 329
18:17:40.867748 08:00:27:2e:19:cd > 08:00:27:eb:f2:44, ethertype IPv4 (0x0800), length 342: 10.0.10.254.67 > 10.0.0.1.67: BOOTP/DHCP, Reply, length 300
//here is dump of eth3(to client) iface: this is what absent above in bad case: replay seen on net1 (eth3) iface of relay
18:19:04.575007 08:00:27:8f:96:7d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.0.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
```
Thanks!Outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/549rake uninstall2022-02-04T08:26:20ZTomek Mrugalskirake uninstallWe do have installation procedure (`rake install`), but there is no uninstall. As reported [here](https://gitlab.isc.org/isc-projects/stork/-/issues/540#note_212156).We do have installation procedure (`rake install`), but there is no uninstall. As reported [here](https://gitlab.isc.org/isc-projects/stork/-/issues/540#note_212156).outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/191Client link-local address and interface not available in commit hook2021-05-29T03:41:26ZNick GallowayClient link-local address and interface not available in commit hook---
name: Client's link-local address and interface should be available in commit hook
about: Add either an option to get both the link local address and interface (in the usual fe80::abcd%IFACE format) or to obtain them separately.
---...---
name: Client's link-local address and interface should be available in commit hook
about: Add either an option to get both the link local address and interface (in the usual fe80::abcd%IFACE format) or to obtain them separately.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Pretty sure. I went over all the relevant code and even tried implementing hooks that look at the packet content but didn't see an option available.
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration? It probably is implemented in Kea, but there's already the better part of an implementation for ISC DHCP written so I think it could be an easy addition to ISC DHCP, and it would overall be a lot less work for anyone not wanting to migrate just yet.
- Are you sure what you would like to do is not possible using some other mechanisms? Not directly, no. It is possible by writing a commit hook that executes a neighbour discovery lookup to obtain the link-local address of the client based on the Mac address of the client, but that seems like an incorrect solution.
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? No.
**Is your feature request related to a problem? Please describe.**
A problem I ran into recently on a popular open source router distribution (OPNsense) is that delegating prefixes to subrouters was broken. I spent some time looking into it and came up with a [solution](https://github.com/opnsense/core/pull/5020), but I think it is less than ideal. It would be better to simply directly have access to the client's link-local address/interface so that routes can be added directly in an on commit hook.
**Describe the solution you'd like**
I think integrating the last five changes here would be along the lines of what I'd go for: https://github.com/Oryon/isc-dhcp/commits/mpalmer/client-address-data-expression
I don't agree with all the specifics of the patches there and would probably present it as a single string to the commit hook, but it's roughly what I'd like.
**Describe alternatives you've considered**
I've considered just migrating to Kea, but as this seems like a relatively small change to improve commit hooks for delegating prefixes it seems like the better option. If ISC DHCP is being deprecated or development halted then migration would be far more urgent.
**Additional context**
Hopefully this request is fairly clear and the GitHub reference for the Oryon/mpalmer patches are also clear.
**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?
Not in my current role, 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?
I am willing but my time is quite limited. I'm not set on any specific solution to this problem.
**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.
I can keep an eye on this issue but if you need to reach out or send me a message that's also fine.https://gitlab.isc.org/isc-projects/kea/-/issues/1903Assess Kea vs. NIST 'Zero trust architecture'2022-11-02T15:10:17ZVicky Riskvicky@isc.orgAssess Kea vs. NIST 'Zero trust architecture'Kea was designed for deployment into a protected environment in a datacenter. Although we are gradually adding more security features, we should do an assessment of which of the NIST Zero Trust architecture requirements we meet and which...Kea was designed for deployment into a protected environment in a datacenter. Although we are gradually adding more security features, we should do an assessment of which of the NIST Zero Trust architecture requirements we meet and which we do not and document that.
https://www.nist.gov/publications/zero-trust-architecturebackloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2715RFC 8914 - DNSSEC validation failures2023-07-11T10:01:41ZVicky Riskvicky@isc.orgRFC 8914 - DNSSEC validation failuresFrom an ISC support customer, another specific use case for extended errors:
"I think our main interest is distinguishing between the class of Server Failed errors that indicate a DNSSEC validation failure and the more transitory sorts ...From an ISC support customer, another specific use case for extended errors:
"I think our main interest is distinguishing between the class of Server Failed errors that indicate a DNSSEC validation failure and the more transitory sorts (network errors, no authoritative DNS servers available, etc.). We have situations in which we have a DNS server with DNSSEC validation enabled forwarding to another DNS server with validation enabled, and when the forwarder returns Server Failed, it's unclear whether to return that answer to the querier or retry resolution without the forwarder. Does that make sense?"Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org