dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-03-09T19:00:29Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/202Enhance dhclient to parse multiple instances in Option 17/43/1252022-03-09T19:00:29Zdongyang wangEnhance dhclient to parse multiple instances in Option 17/43/125---
name: Feature request
about: Enhance dhclient to parse multiple instances in Option 17/43/125
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure...---
name: Feature request
about: Enhance dhclient to parse multiple instances in Option 17/43/125
---
**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? Perhaps it's a
good time to consider migration?
This is for DHCP client, and KEA doesn't support client.
- Are you sure what you would like to do is not possible using some other mechanisms?
Not sure, maybe there also has other way.
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
Sorry, I commit to here first. Upload the patch as an attachment.
[0001-Enhance-dhclient-to-parse-multiple-instances-in-Opti.patch](/uploads/0daaff86a3432d950fb316177a0666fb/0001-Enhance-dhclient-to-parse-multiple-instances-in-Opti.patch)
**Is your feature request related to a problem? Please describe.**
When DHCP server sends a single instance in Option 17/43/125 from the dhclient-exit-hooks,
dhclient can parse it well.
But if DHCP server sends multiple instances, dhclient only can parse the first one.
**Describe the solution you'd like**
Use a do-while to parse each "struct option_cache-->option" in the oclist.
**Describe alternatives you've considered**
**Additional context**
**Funding its development**
**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! It's my pleasure, I'm very glad to do these.
**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.
Maybe here has a typo: >>we may send you a message on **github **with questions when we have them.
We are on GitLab now :)
Using GitLab can contact me, thanks.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/184[PATCH] relay: fix IPv6 multicast address in documentation2022-03-09T19:11:59ZFoster Snowhill[PATCH] relay: fix IPv6 multicast address in documentation```diff
From e6ca44a168b5ae07cb2b6d7aa9c7548eaf82b7ff Mon Sep 17 00:00:00 2001
From: Foster Snowhill <2516-forst@users.noreply.gitlab.isc.org>
Date: Sun, 25 Apr 2021 15:23:16 +0200
Subject: [PATCH] relay: fix IPv6 multicast address in do...```diff
From e6ca44a168b5ae07cb2b6d7aa9c7548eaf82b7ff Mon Sep 17 00:00:00 2001
From: Foster Snowhill <2516-forst@users.noreply.gitlab.isc.org>
Date: Sun, 25 Apr 2021 15:23:16 +0200
Subject: [PATCH] relay: fix IPv6 multicast address in documentation
In the dhcrelay source code, parse_upstream() function by default defines the
destination address to be the All_DHCP_Servers multicast group (ff05::1:3).
However, the documentation says that it uses All_DHCP_Relay_Agents_and_Servers
(ff02::1:2). This is inconsisent with the implementation.
This commit fixes the documentation to also specify All_DHCP_Servers as the
default multicast group.
---
relay/dhcrelay.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/relay/dhcrelay.8 b/relay/dhcrelay.8
index 53cd28bf..10ebfe3d 100644
--- a/relay/dhcrelay.8
+++ b/relay/dhcrelay.8
@@ -325,7 +325,7 @@ forwarded. At least one \fB-u\fR option must be included in the command
line when running in DHCPv6 mode. The interface name \fIifname\fR is a
mandatory parameter. The destination unicast or multicast address can be
specified by \fIaddress%\fR; if not specified, the relay agent will forward
-to the DHCPv6 \fIAll_DHCP_Relay_Agents_and_Servers\fR multicast address.
+to the DHCPv6 \fIAll_DHCP_Servers\fR multicast address.
.PP
It is possible to specify the same interface with different addresses
more than once, and even, when the system supports it, to use the same
--
2.31.1
```
---
This patch is against `master` (commit 79110e525e0584d195327d31f4ee67e6a5e2fe7a).
For reference, the relevant line in `parse_upstream()` function: https://gitlab.isc.org/isc-projects/dhcp/-/blob/79110e525e0584d195327d31f4ee67e6a5e2fe7a/relay/dhcrelay.c#L1532
If possible, can I also please get a project allocation, so that in the future I can submit proper merge requests? Thanks!Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/161Sending old_ variables in BOUND callout2022-03-09T18:57:54Zcyrilbur-adderSending old_ variables in BOUND callout---
name: Sending old_ variables in BOUND callout
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or s...---
name: Sending old_ variables in BOUND callout
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org. If you really need to report it here, please set the confidential
field to true.
I have a patch on github please see here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
If you would be so kind as to allow me to post it here in your gitlab as per https://github.com/isc-projects/dhcp/blob/31e68e5e3b863a4859562e0bb808888d74af7497/CONTRIBUTING.md
**To Reproduce**
Everything is outlined in the commit message of the patch here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
**Expected behavior**
Everything is outlined in the commit message of the patch here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
**Environment:**
Not really relevant since I have a patch
**Additional Information**
None
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
NA
- Are you sure what you would like to do is not possible using some other mechanisms?
No
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
I've emailed the patch to dhcp-workers, no response
**Is your feature request related to a problem? Please describe.**
It is a patch to a likely bug
**Describe the solution you'd like**
Merge the patch
**Describe alternatives you've considered**
None
**Additional context**
None
**Funding its development**
I'm trying to provide you with a patch
**Participating in development**
I'm trying to provide you with a patch
**Contacting you**
Please contact me here or on github.https://gitlab.isc.org/isc-projects/dhcp/-/issues/152Support DHCP relay on interfaces with zero MAC address2022-03-09T19:06:03ZQingtao CaoSupport DHCP relay on interfaces with zero MAC addressThe dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC a...The dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC address, the ipsecX interfaces built upon such wwanX interfaces won't have L2 addresses, resulting in the dhcrelay daemon unable to use them.
I will try to propose a patchset to support such interfaces.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/135Virtual interface support2020-11-12T20:43:18ZFrederic BorVirtual interface support---
name: Virtual interface support
about: with the rise of VTI IPsec usage, there is a need for virtual interface support in dhcp relay.
---
**Is your feature request related to a problem? Please describe.**
I would like to use a rem...---
name: Virtual interface support
about: with the rise of VTI IPsec usage, there is a need for virtual interface support in dhcp relay.
---
**Is your feature request related to a problem? Please describe.**
I would like to use a remote dhcp server and relay request to it threw VTI interfaces.
**Describe the solution you'd like**
I'd like to have support for virtual interfaces so I can relay dhcp requests threw them.
**Describe alternatives you've considered**
The only alternative when using VTI is to have a local dhcp server, instead of a remote one. But when you start to have some small remote sites, it's a lot less convenient than simply activate dhcp relay and setting up the ip of the remote server.
**Additional context**
The attached patch is implementing this for IFT_TUNNEL interface type.
I had some trouble with BPF, getting the whole packet. I was only having the first 67 bytes. I'm not sure why. It was working correctly in a small POC code environnement but not within dhcrelay. I managed do get it works by adding a "load (uint)(-1) into the accumulator" instruction before returning the packet.
We are using this patch in production since march on a dozen of firewalls, it's working well. It's untested except on pfSense/FreeBSD.
**Participating in development**
I am willing to participate in the feature development, discusions, tests.
I will see how to do this on linux.
Could I have a project allocation to this intent ?
**Contacting you**
Here is nice, or github.
[vti_support.patch](/uploads/0d96555a7ae7eec4a4c537079f364c28/vti_support.patch)4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/94DHCP relay agent will not discover interfaces if they are down when dhcrelay ...2022-03-09T19:03:52ZJoe LeVequeDHCP relay agent will not discover interfaces if they are down when dhcrelay startsCurrently, dhcrelay will not discover interfaces if they are down at the time the relay agent starts up. If the interface(s) are down at the moment dhcrelay enumerates the interfaces, yet they get brought up any time later, the relay wil...Currently, dhcrelay will not discover interfaces if they are down at the time the relay agent starts up. If the interface(s) are down at the moment dhcrelay enumerates the interfaces, yet they get brought up any time later, the relay will discard packets received on these interfaces and log the message, `Discarding packet received on <iface_name> interface that has no IPv4 address assigned`.
With this patch, the relay agent will discover all configured interfaces, whether or not they are up at the time the relay agent starts. Thus, the state of the configured interfaces can be down when the relay agent starts and brought up during the lifetime of the relay agent process, and the relay agent will relay packets as expected; it will not discard them. A DHCP relay agent shouldn't ignore a configured interface if the interface happens to be down when it starts up.
The patch is the addition of one line in common/discover.c, after line 638.
Current code:
```c
/* Skip non broadcast interfaces (plus loopback and
point-to-point in case an OS incorrectly marks them
as broadcast). Also skip down interfaces unless we're
trying to get a list of configurable interfaces. */
if ((((local_family == AF_INET &&
!(info.flags & IFF_BROADCAST)) ||
#ifdef DHCPv6
(local_family == AF_INET6 &&
!(info.flags & IFF_MULTICAST)) ||
#endif
info.flags & IFF_LOOPBACK ||
info.flags & IFF_POINTOPOINT) && !tmp) ||
(!(info.flags & IFF_UP) &&
state != DISCOVER_UNCONFIGURED))
continue;
```
Proposed patch:
```c
/* Skip non broadcast interfaces (plus loopback and
point-to-point in case an OS incorrectly marks them
as broadcast). Also skip down interfaces unless we're
trying to get a list of configurable interfaces. */
if ((((local_family == AF_INET &&
!(info.flags & IFF_BROADCAST)) ||
#ifdef DHCPv6
(local_family == AF_INET6 &&
!(info.flags & IFF_MULTICAST)) ||
#endif
info.flags & IFF_LOOPBACK ||
info.flags & IFF_POINTOPOINT) && !tmp) ||
(!(info.flags & IFF_UP) &&
state != DISCOVER_UNCONFIGURED &&
state != DISCOVER_RELAY))
continue;
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/49need to be able to specify DNS domain for ldap2020-04-27T13:42:36ZGhost Userneed to be able to specify DNS domain for ldapIn a large system, LDAP servers can change. We don't want to have to reconfigure every service that uses LDAP. DNS allows us to use SRV records to locate the servers. Unfortunately, although Openldap has support for looking up the LDAP s...In a large system, LDAP servers can change. We don't want to have to reconfigure every service that uses LDAP. DNS allows us to use SRV records to locate the servers. Unfortunately, although Openldap has support for looking up the LDAP servers using SRV records, the normal hostname and URI processing doesn't use that support. You have to call for it explicitly.
Also, the existing code doesn't allow you to specify a URI. Unless you exploit bugs in the parser, this limits you to specifying a single host.
This patch does two things:
1. If ldap_server starts with ldap: or ldaps:, it is taken to be the URI, and is passed to ldap_initialize unmodified. (I make no guarantees that ldaps: will actually work, but I've tested with ldap:)
2. If ldap_server starts with DNS:, the rest is taken to be a domainname. DNS service location is used to find the hosts and ports to build the URI. (This convention is taken from nslcd. There's a convention involving hex-encoded characters that seems unnecessarily obscure.)
If neither of these things is true, it is treated as a hostname, as before.
[dhcp-dns-domain.patch](/uploads/a6a14a5b22737126e38362050ba3d8a9/dhcp-dns-domain.patch)
Caveats:
1) While I pass on URI's starting with ldaps:, I have no idea whether they work. I can't get either SSL or TLS to work at all, and I've tried lots of different options.
2) Be aware that these patches are with respect to the code in Centos 7.https://gitlab.isc.org/isc-projects/dhcp/-/issues/32undefined symbols in libomapi2023-03-07T09:15:20ZEnrico Scholzundefined symbols in libomapi**Describe the bug**
Calling `dhclient` fails here with
```
dhclient: symbol lookup error: /usr/lib/libomapi.so.0: undefined symbol: dns_rootname
```
This is caused by a combination of `-Wl,-as-needed` and `-Wl,-no-add-nedded` linker...**Describe the bug**
Calling `dhclient` fails here with
```
dhclient: symbol lookup error: /usr/lib/libomapi.so.0: undefined symbol: dns_rootname
```
This is caused by a combination of `-Wl,-as-needed` and `-Wl,-no-add-nedded` linkerflags (although sounding similarly, they have diffierent semantics and latter one is the default e.g. on Fedora).
Because code in `libomapi.so` uses functionality from `libdns` and other libraries, it should be linked against them.
I fixed it with [omapilibs.patch](/uploads/ff0ba07e0db378984318714d188972e0/omapilibs.patch)
```diff
Index: dhcp-4.4.1/omapip/Makefile.am.in
===================================================================
--- dhcp-4.4.1.orig/omapip/Makefile.am.in
+++ dhcp-4.4.1/omapip/Makefile.am.in
@@ -11,6 +11,10 @@ libomapi_@A@_SOURCES = protocol.c buffer
handle.c message.c convert.c hash.c auth.c inet_addr.c \
array.c trace.c toisc.c iscprint.c isclib.c
+libomapi_@A@_LIBADD = $(BINDLIBDNSDIR)/libdns.@A@ \
+ $(BINDLIBIRSDIR)/libirs.@A@ \
+ $(BINDLIBISCCFGDIR)/libisccfg.@A@
+
man_MANS = omapi.3
EXTRA_DIST = $(man_MANS)
```
**Environment:**
- seen with OpenEmbedded `thud` (http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/dhcp?h=thud)4.5.0-beta