Pi-hole 5.0 fails to create ipv6 ranges for DHCP

[michi_e]

Hi,
I've been running Pi-hole on a Raspberry Pi Zero (latest Raspbian) for quite a time without any problems. Thanks to the devs for this positive experience.

But since having updated to Pi-hole 5.0, I am experiencing some difficulties with DHCPv6: When using the standard configuration, Pi-hole wont't assign any IPv6 configuration to the clients. pihole.log shows no information about IPv6 ranges as it would for the previous version or a standalone dnsmasq.

To be honest, as there is a simple workaround (manually maintaining the address ranges) this is rather a bit annoying than problematic to me. But nevertheless, I'd be interested in finding out whether the problem is—as usually—to be found in front of the screen or rather in the software.

Thanks in advance for any information and/or help on that!

Expected Behaviour:

When using DHCPv6, Pi-hole should create address ranges to be distributed corresponding to the networks the interface is assigned to. Accordingly, it shold assign adresses from these ranges to clients requesting them via DHCP.

Actual Behaviour:

Since updating to version 5.0, Pi-hole-FTL fails to generate these address ranges. Consequently, clients are not assigned addresses via DHCP. Instead, when a client requests DHCPv6 configuration, the following is logged:

dnsmasq-dhcp[2738]: no address range available for DHCPv6 request via eth0

Debug Token:

https://tricorder.pi-hole.net/9bsy37c1tl

[Bucking_Horn]

Your debug log looks normal.
Specifically, your Pi-hole is configured to hand out IPv6 addresses via DHCPv6 should a client request so:

*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d
-rw-r--r-- 1 root root 629 Jun  7 12:07 /etc/dnsmasq.d/02-pihole-dhcp.conf
   dhcp-range=::100,::1ff,constructor:eth0,ra-names,slaac,168h

The "no address range available" message you encountered indicates that Pi-hole may not be aware of an IPv6 prefix to attach to its address range.

What's the output of the following command when run from your Pi-hole machine:

ip -6 address show

[michi_e]

Hi Bucking_Horn,

thanks for your quick reply.

@Bucking_Horn

Your debug log looks normal.
Specifically, your Pi-hole is configured to hand out IPv6 addresses via DHCPv6 should a client request so:

Well, I expected that as the exact same configuration works with both Pi-hole 4 and a regular dnsmasq.

@Bucking_Horn

What's the output of the following command when run from your Pi-hole machine:

ip -6 address show

It shows the IPv6 addresses of Pi-hole's network interface:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
     inet6 2002:DEAD:BEEF:0:20e:c6ff:feba:ddad/64 scope global dynamic mngtmpaddr noprefixroute
        valid_lft 6639sec preferred_lft 3039sec
     inet6 fd00::cafe/64 scope global dynamic noprefixroute
        valid_lft 604005sec preferred_lft 604005sec
     inet6 fe80::20e:c6ff:feba:ddad/64 scope link
        valid_lft forever preferred_lft forever

So everything should work as expected, shouldn't it?

[Bucking_Horn]

(Seeing you already tried this, I took the freedom to further obfuscate your device's IPv6 addresses, as MAC address was encoded in the last 4 blocks.)

Your IPv6 addresses look ok.
I was especially looking for prefix length, as setting up a static IPv6 address could preclude a prefix by stating a /128 prefix length - yours is /64, so no cause for concern here.
But I notice that your debug log shows an additional global IPv6 address for your Pi-hole that ends in cafe - if you have stripped that from the output and set it statically, consider removing that from your config.

@michi_e

Well, I expected that as the exact same configuration works with both Pi-hole 4 and a regular dnsmasq.

Could you elaborate on this?
Do you have a separate dnsmasq instance running parallel to Pi-hole? What version is it?

[michi_e]

@Bucking_Horn

I took the freedom to further obfuscate your device's IPv6 addresses

Thanks, seem to be a bit unfocused today ...

@Bucking_Horn

But I notice that your debug log shows an additional global IPv6 address for your Pi-hole that ends in cafe - if you have stripped that from the output and set it statically, consider removing that from your config.

Ah, that was a leftover that was only attached temporarily.

@Bucking_Horn

@michi_e

Well, I expected that as the exact same configuration works with both Pi-hole 4 and a regular dnsmasq.

Could you elaborate on this?
Do you have a separate dnsmasq instance running parallel to Pi-hole? What version is it?

No, I don't have dnsmasq running parallel to Pi-hole. And I don't think this should work, or would it?
After experiencing the issue, I tried to nail it down a little bit (misconfiguration etc.), so I installed dnsmasq. First, I installed dnsmasq via apt and saw DHCPv6 work—but this was version 2.8, which also had no problems in previous Pi-hole. So I tried with the current version of dnsmasq (2.81) which also works.

Any ideas?

[Bucking_Horn]

@michi_e

Ah, that was a leftover that was only attached temporarily.

We could check your dhcpcd.conf for any additional leftovers:
For your Pi-hole machine, what's the output of:

grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf

You may also want to reverify if it would work now that you've removed that extra IPv6 address.
To that end, you could add a line
log-dhcp
to /etc/dnsmasq.d/99-dhcp-log.conf and then issue

pihole restartdns

Then reboot/reconnect a client device and see if /var/log/pi-hole.log yields any additional dnsmasq-dhcp messages.
Note that not all devices are alike when it comes to DHCPv6, e.g. Android devices make use of SLAAC exclusively, so will never request an IP address via DHCPv6.

[michi_e]

@Bucking_Horn

We could check your dhcpcd.conf for any additional leftovers:

I don't think there should be any more of them.

@Bucking_Horn

For your Pi-hole machine, what's the output of:

grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf

Nothing special, I suppose:

hostname
duid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
option ntp_servers
require dhcp_server_identifier
interface eth0
static ip_address=10.0.5.1/20
static ip6_address=fd00::cafe/64
static routers=10.0.1.1 
static domain_name_servers=10.0.1.7 fd00::dada

@Bucking_Horn

You may also want to reverify if it would work now that you've removed that extra IPv6 address.

The behavior stays the same.

@Bucking_Horn

Then reboot/reconnect a client device and see if /var/log/pi-hole.log yields any additional dnsmasq-dhcp messages.

As mentioned in my first post, when a client requests DHCPv6, the only message in the log is:

dnsmasq-dhcp[2738]: no address range available for DHCPv6 request via eth0

@Bucking_Horn

Note that not all devices are alike when it comes to DHCPv6, e.g. Android devices make use of SLAAC exclusively, so will never request an IP address via DHCPv6.

I'm aware of that.

[doncarajo]

Does your Pi have a public IPv6 address? I had the same problem and it was fixed by putting the public IPv6 address after "static ip6_address=" in dhcpcd.conf with the /64 after it.

[Bucking_Horn]

@michi_e

As mentioned in my first post, when a client requests DHCPv6, the only message in the log is:

dnsmasq-dhcp[2738]: no address range available for DHCPv6 request via eth0

There should be some RTR-SOLICIT and RTR-ADVERT messages, at least for your fd00:: prefix.

@doncarajo

I had the same problem and it was fixed by putting the public IPv6 address after "static ip6_address=" in dhcpcd.conf with the /64 after it.

Thanks, doncarajo - we've already checked prefix length for static IPs earlier.

michi_e, your dhcpcd.conf as posted above looks inconspicious to me. It shows you are not using public IPv6 addresses and you correctly attach prefixes to IPv6 addresses as well.

However, I noticed you instruct dhcpcd to generate a DUID.
This is perfectly valid, so the following may be a bit of a far call:
duid may only ever cause trouble if you happened to run an additional machine from the same image in the same network, as that DUID gets stored in /etc/dhcpcd.duid, but needs to be unique within your network.
If you do not run such a second machine, this would not be related to your issue at all.

@michi_e

First, I installed dnsmasq via apt and saw DHCPv6 work—but this was version 2.8, which also had no problems in previous Pi-hole. So I tried with the current version of dnsmasq (2.81) which also works.

This seems to imply that somehow the new dnsmasq version of Pi-hole 5 is involved.

I have tested both Pi-hole v4 and 5.0 when investigating doncarajo's issue (where this suspicion also arose, but wasn't confirmed) - it might be worth to read my analysis results in that post.
While I was able to provoke the same "no address range available" message by disabling distribution of a ULA prefix, I could not reproduce the error itself (at least not until the prefix length root cause was identified later).

[michi_e]

@doncarajo

Does your Pi have a public IPv6 address?

Yes, but not a static one as the prefix changes from time to time.

@Bucking_Horn

This seems to imply that somehow the new dnsmasq version of Pi-hole 5 is involved.

Actually, pihole's dnsmasq was my first suspect which made me play around with the different versions.

@Bucking_Horn

I have tested both Pi-hole v4 and 5.0 when investigating doncarajo's issue (where this suspicion also arose, but wasn't confirmed) - it might be worth to read my analysis results in that post.

Yes, I can confirm: it really is. I've read (and tried to understand) the whole thread before posting my initial question as it is one of the few citing the "no address range ..." log message. But I could not clearly relate it to my issue.

@Bucking_Horn

While I was able to provoke the same " no address range available " message by disabling distribution of a ULA prefix, I could not reproduce the error itself (at least not until the prefix length root cause was identified later).

Which is not the case for me. My router is set to not distribute a ULA prefix. And the behaviour wouldn't change if it was set to distribute one (already tried this for testing).

However, I recently discovered that it seems to work as expected if I set Pi-hole to listen only to eth0 (was set to 'all interfaces, all origins'). Since I'm perfectly fine with this listening behaviour, I think we can consider my specific problem as solved. Thank you for your efforts and thanks to @doncarajao for his inupt.

Nevertheless, I would of course be interested to know what actally caused this behaviour or why the solution/workaround works—especially because it works flawlessly with oher versions of dnsmasq. So if anybody feels like enlightening me ...

Thanks again for your help!