DHCPv6 not being picked up by Linux clients

[RainmakerRaw]

Prerequisites

• [X] I have checked the Wiki and Discussions and found no answer

• [X] I have searched other issues and found no duplicates

• [X] I want to report a bug and not ask a question

Operating system type

Linux, Other (please mention the version in the description)

CPU architecture

64-bit ARM

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

0.107.20

Description

What did you do?

Enabled DHCP for v4 in the webUI. I noticed the IPv6 server couldn't be enabled, as the IPv6 address was not clickable. I added a newly generated IPv6 private address (fd94:8b3c:1b9e:c5ae::1/64) to the NIC using nmtui, and AGH instantly detected this and allowed me to enable DHCPv6.

I set the range from fd94:8b3c:1b9e:c5ae::2 to ff, and saved the changes. No local clients (Linux, iOS, macOS) are picking up an IPv6 address, but they are getting the new IPv4 and DNS settings. I also tried with ra_allow_slaac: true to no avail.

Expected result

Local clients should automatically (almost instantly) pick up an IPv6 address, from either DHCPv6 or SLAAC.

Actual result

Only one local client, a Synology DiskStation, picked up an IPv6 address from the local subnet automatically. I didn't have to change anything, it just appeared in the list of leases almost instantly, using the first IP in the available pool. This means 'something' is working, but out of around 30 local devices it's the only one that detected the DHCPv6 server.

Screenshots (if applicable)

Additional information

I tried manually toggling settings in my Linux clients (Fedora, Debian, Void) and tried literally every permutation in NetworkManager (Auto, DHCP only, various permutations of privacy extensions or none). Nothing allows clients to pick up the DHCPv6 server running on AGH.

My DiskStation remains the only client which instantly saw an IP and it's showing as the only IPv6 lease in the AGH webUI. I can ping6 the AGH server from the DiskStation, and I can ping6 the DiskStation in return from the AGH server. However, no other device can see the DHCPv6 server or get an address.

Is RA broken? Have I missed something else? I feel dumb! I tried enabling an IPv6 DHCP server in OPNSense in libvirt, and connected devices all instantly picked up an IPv6 address using DHCPv6 or SLAAC so I don't think it's anything I'm doing, or anything with the clients themselves.

I have ensured ICMPv6 is enabled across all devices. The machine running AGH server is actually a Radxa ROCK 5 model B (Ubuntu Focal 20.04.5) and has no firewall running. I've checked with clients running Linux, macOS, Windows 11, iOS and others and nothing but the Synology NAS has picked up a v6 IP. I also tried disabling ra_allow_slaac again in the AGH config and restarted the service, to be safe, but to no avail. Any ideas please?

[RainmakerRaw]

As an update, the (only) Windows box in the house has picked up a DHCPv6 lease after reboot. That leaves 2 clients out of >30 with an IPv6 address. No joy on any of the other devices or OS, including various Linux (systemd and systemd-free), *BSDs, macOS, iOS, iPadOS, FireTV OS and so on. It's starting to feel like a config issue, and therefore not suitable for here, albeit it's something other users may stumble on also. I can't see what, though, if that's the case.

[THEDARKK]

Same

[THEDARKK]

I fixed my problem by taking this container. https://hub.docker.com/r/networkboot/dhcpd

[Gandulf78]

I fixed my problem by taking this container. https://hub.docker.com/r/networkboot/dhcpd

I have also some persisting issues with DHCP. Would you have some guidelines to provide on how to use this DHCPD tool ? (configuration files)

[THEDARKK]

I fixed my problem by taking this container. https://hub.docker.com/r/networkboot/dhcpd

I have also some persisting issues with DHCP. Would you have some guidelines to provide on how to use this DHCPD tool ? (configuration files)

# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
# option domain-name "example.org";
option domain-name-servers 192.168.1.11;

default-lease-time 86400;
max-lease-time 86400;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
#log-facility local7;

# No service will be given on this subnet, but declaring it helps the 
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.20 192.168.1.200;
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.1;
}

host SHIELD {
  hardware ethernet 00:04:XX:XX:XX:XX;
  fixed-address 192.168.1.100;
}

#subnet 10.254.239.0 netmask 255.255.255.224 {
#  range 10.254.239.10 10.254.239.20;
#  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

#subnet 10.254.239.32 netmask 255.255.255.224 {
#  range dynamic-bootp 10.254.239.40 10.254.239.60;
#  option broadcast-address 10.254.239.31;
#  option routers rtr-239-32-1.example.org;
#}

# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
#  range 10.5.5.26 10.5.5.30;
#  option domain-name-servers ns1.internal.example.org;
#  option domain-name "internal.example.org";
#  option routers 10.5.5.1;
#  option broadcast-address 10.5.5.31;
#  default-lease-time 600;
#  max-lease-time 7200;
#}

# Hosts which require special configuration options can be listed in
# host statements.   If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

#host passacaglia {
#  hardware ethernet 0:0:c0:5d:bd:95;
#  filename "vmunix.passacaglia";
#  server-name "toccata.example.com";
#}

# Fixed IP addresses can also be specified for hosts.   These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.   Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
#  hardware ethernet 08:00:07:26:c0:a5;
#  fixed-address fantasia.example.com;
#}

# You can declare a class of clients and then do address allocation
# based on that.   The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {
#  match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}

#shared-network 224-29 {
#  subnet 10.17.224.0 netmask 255.255.255.0 {
#    option routers rtr-224.example.org;
#  }
#  subnet 10.0.29.0 netmask 255.255.255.0 {
#    option routers rtr-29.example.org;
#  }
#  pool {
#    allow members of "foo";
#    range 10.17.224.10 10.17.224.250;
#  }
#  pool {
#    deny members of "foo";
#    range 10.0.29.10 10.0.29.230;
#  }
#}

[akyoto]

Only one local client, a Synology DiskStation, picked up an IPv6 address from the local subnet automatically. I didn't have to change anything, it just appeared in the list of leases almost instantly, using the first IP in the available pool. This means 'something' is working, but out of around 30 local devices it's the only one that detected the DHCPv6 server.

Yep, I have the exact same problem.

Only one PC (the one I used to configure Adguard DHCP) picked up the first IP in the range instantly, with the expires time set to 0001-01-01T00:00:00Z.

I confirmed that clients can see the DHCPv4 via:

sudo nmap --script broadcast-dhcp-discover -e $INTERFACE

I get a response from AdGuard DHCP IPv4. However the following...

sudo nmap -6 --script broadcast-dhcp6-discover -e $INTERFACE

...shows no output. Hence clients don't pick up DHCPv6 and can't get the correct IP / DNS configurations.

[dukzcry2]

Still valid I see response when using nmap

июн 27 10:24:40 <removed> adguardhome[746159]: [dhcpv6] 2024/06/27 10:24:40 Handling request from [<removed>%br0]:546

Starting Nmap 7.94 ( https://nmap.org ) at 2024-06-27 10:24 MSK
Pre-scan script results:
| broadcast-dhcp6-discover: 
|   Interface: enp42s0
|     Message type: Advertise
|     Transaction id: 258544
|     Options
|       Client identifier: MAC: <removed>; Time: 2024-06-27T07:24:40
|       Server identifier: MAC: <removed>; Time: 2024-06-27T04:24:30
|       Non-temporary Address: fd7b:6df9:6188:4fd3::1
|_      Error: Code: 0; Message: success
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.05 seconds

But none of my NetworkManager controlled Linux hosts pick up the address. There is no issue if using dnsmasq instead of AdGuardHome