dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-03-09T19:11:59Zhttps://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/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/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/dhcp/-/issues/204dhcrelay -6 does not work if there are interface aliases up in the system2022-03-09T19:02:55ZSantiagodhcrelay -6 does not work if there are interface aliases up in the systemHi there,
I've been hit by this issue on Debian stretch through sid (the latest including 4.4.1, I've been unable to test on 4.4.2).
dchrelay -6 doesn't start if there are interface aliases up in the
system:
```
# /usr/sbin/dhcrel...Hi there,
I've been hit by this issue on Debian stretch through sid (the latest including 4.4.1, I've been unable to test on 4.4.2).
dchrelay -6 doesn't start if there are interface aliases up in the
system:
```
# /usr/sbin/dhcrelay -6 -pf /var/run/dhcrelay6.pid -l vlan.881 -u 2001:db8:cafe::2%vlan.880
Internet Systems Consortium DHCP Relay Agent 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Bound to *:547
Listening on Socket/vlan.881:0
Sending on Socket/vlan.881:0
Listening on Socket/vlan.880:0
Sending on Socket/vlan.880:0
Listening on Socket/vlan
Sending on Socket/vlan
setsockopt: IPV6_JOIN_GROUP: Address already in use
If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug. These pages explain the proper
process and the information we find helpful for debugging.
exiting.
```
The above error can be reproduced with inside a container with the following /etc/network/interfaces:
```
auto lo
iface lo inet loopback
auto vlan
iface vlan inet dhcp
auto vlan.880
auto vlan.880:0
iface vlan.880 inet static
address 192.168.133.1/24
iface vlan.880 inet6 static
address 2001:db8:cafe::1/64
iface vlan.880:0 inet static
address 10.0.133.1/16
auto vlan.881
auto vlan.881:0
iface vlan.881 inet static
address 192.168.131.1/24
iface vlan.881 inet6 static
address 2001:db8:cafe:1::1/64
iface vlan.881:0 inet static
address 10.1.131.1/16
```
Just removing (or commenting out) the interface aliases entries makes dchrelay -6 happy (again).
Please note the `-l` and `-u` filters do not work. But that's another bug.
This seems similar to #88. The patch attached there doesn't fix the problem.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/169dhcrelay doesn't set remote_port with `-p` option2022-03-09T19:06:28ZJonah Caplandhcrelay doesn't set remote_port with `-p` option---
name: dhcrelay doesn't set remote_port with `-p` option
about:
---
**Describe the bug**
Run a dhclient, dhcrelay, and dhcpd server using non standard ports. dhcrelay doesn't set the port on replies to the client.
**To Reproduce*...---
name: dhcrelay doesn't set remote_port with `-p` option
about:
---
**Describe the bug**
Run a dhclient, dhcrelay, and dhcpd server using non standard ports. dhcrelay doesn't set the port on replies to the client.
**To Reproduce**
Make sure target2->target1 is on a different subnet from target3->target1 so it doesn't get the reply from target3:
- Target1, running `dhcrelay -d -p 60 172.16.129.103`
- Target2, running `dhclient vmx1 -d -p 61`
- Target3, running `dhcpd -d -p 60 vmx0`
**Expected behavior**
dhcrelay relays the reply to dhclient on port 61, but the port on the outgoing BOOTREPLY is 0.
**Environment:**
**Additional Information**
suggested diff
```
if (!local_port) {
...
} else {
remote_port = htons(ntohs(local_port) + 1);
}
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/270dhcrelay error2022-11-01T15:50:00ZmyNameBorisdhcrelay errorIf there are more than 3000 interfaces, then I get an error:
```
Unable to register fd with library out of range
Can't register I/O handle for vlan3051.101: out of range
```If there are more than 3000 interfaces, then I get an error:
```
Unable to register fd with library out of range
Can't register I/O handle for vlan3051.101: out of range
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/56relay: Segfault on replies not intended for us2022-03-09T19:03:21ZGhost Userrelay: Segfault on replies not intended for us**Describe the bug**
Segfault of `dhcrelay -a` upon receipt of answer packet not intended for us, but with a circuit ID that resolves to a local interface.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure this setup with a...**Describe the bug**
Segfault of `dhcrelay -a` upon receipt of answer packet not intended for us, but with a circuit ID that resolves to a local interface.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure this setup with all relevant routes (think of R1 and R2 as failover partners in a VRRP setup with dynamic routing):
* R1 has interfaces
* eth0 with address 10.0.0.1/24 (backbone)
* eth1 with address 10.0.1.1/24 (clients1)
* eth2 without address
* eth3 without address
* R2 has interfaces
* eth0 with address 10.0.0.2/24 (backbone)
* eth1 without address
* eth2 with address 10.0.2.2/24 (clients2)
* eth3 with address 10.0.3.2/24 (to DHCP-Server)
1. Run `dhcrelay -a -iu eth0 -iu eth3 -id eth1 -id eth2 10.0.3.100` on both R1 and R2
2. A client in 10.0.1.1/24 (clients1) sends a request via relay R1, that relays it to 10.0.3.100. The relayed packet is routed by R2 like a regular IP packet
3. The server 10.0.3.100 replies to R1 via unicast
4. dhcrelay on R2 sees the answer packet and inspects it. It doesn't find a matching interface via giaddr, but via Circuit ID, which contains "eth1". But eth1 doesn't have an address configured that it could use to send the reply, so dhcrelay segfaults.
**Expected behavior**
R2 should ignore the packet.
**Environment:**
- ISC DHCP version: Tested on 4.3.5-3+deb9u1, but relevant code is present in master
- OS: Debian Stretch x64
**Additional Information**
The segfault itself is caused [in dhcrelay.c](https://gitlab.isc.org/isc-projects/dhcp/blob/master/relay/dhcrelay.c#L912):
```c
if (send_packet(out, NULL, packet, length, out->addresses[0], &to, htop) < 0) {
```
Because `strip_relay_agent_options()` earlier set `out` to eth1, `out->addresses` is a NULL reference because eth1 doesn't have any addresses.
The segfault should be avoided by checking that `out` is not only non-NULL but also has addresses:
```diff
--- a/relay/dhcrelay.c
+++ b/relay/dhcrelay.c
@@ -902,7 +902,7 @@ do_relay4(struct interface_info *ip, struct dhcp_packet *packet,
strip_relay_agent_options(ip, &out, packet, length)))
return;
- if (!out) {
+ if (!out || out->address_count == 0) {
log_error("Packet to bogus giaddr %s.\n",
inet_ntoa(packet->giaddr));
++bogus_giaddr_drops;
```
(This whole bug report would have been much easier as a merge request, but I'm not allowed to clone the repository)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.Outstanding