PiHole not assigning IPs and due to netmask

Help
1

Expected Behavior:
Pi assigns all devices an IPv4 address as they connect to the network. Devices are able to access the internet. Pi blocks blacklisted domains.

Actual Behavior:
Some devices cannot connect to the network at all. I can not find any discernible pattern as to which devices can and which cannot. Devices on the network can access the internet, but domain blocking does not function. Multiple warnings appear in the diagnostic logs.

Details:
I am running Pi-hole on a Pi 5, Raspian OS, outside docker. My router does not support assigning the Pi as the DNS and so I have to configure it as the DHCP server for my network. When I try to set the Pi as the DHCP server it fails to assign IP addresses to some devices and not others. I am unclear as to why.

The Pi-hole diagnosis keeps throwing the following 2 errors:

DHCP range 192.168.1.2 -- 192.168.1.254 is not consistent with netmask 255.255.255.255

No address range available for DHCP request via eth0

The contents of the 02-pihole-dhcp.conf read

dhcp-authoritative
dhcp-range=192.168.1.2,192.168.1.254,24h
dhcp-option=option:router,192.168.1.1
dhcp-leasefile=/etc/pihole/dhcp.leases
#quiet-dhcp
domain=local
local=/local/
dhcp-rapid-commit

There's no mention of a netmask anywhere on the Pi-hole GUI or the router settings, so I suspected this might have something to do with the ifconfig. Output:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.2 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::2bd2:e5ff:b9e2:2707 prefixlen 64 scopeid 0x20
ether 2c:cf:67:2e:07:f6 txqueuelen 1000 (Ethernet)
RX packets 5049 bytes 1281001 (1.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2415 bytes 2993767 (2.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 106

Suspecting the netmask might be causing the issue, I reset it to 255.255.255.0, but when I reconnected the Pi it immediately reset to 255.255.255.255.

Debug log below: https://tricorder.pi-hole.net/0fmH5786/

Any help would be greatly appreciated.

Addendum: This is either helpful context or a red herring. While I was writing this the following warnings also occurred

no address range available for DHCP request via docker0

AFAIK I am not running Pi-hole through docker, but I do have other containers in docker on the pi. This was not generated while accessing those.

ignoring query from non-local network 192.168.1.48 (logged only once)

There is no .48 on our network.

2

It was, at the time that IP has been logged (and probably still is).

Your RPi 5's eth0 interface has been configured for a /32 netmask (i.e. 255.255.255.255):

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
    192.168.1.2/32

How did you assign a static IP to your RPi 5?

3

I tried setting it on the router but ran into issues with that (unfortunately I don't remember what the issue was.)

After doing some searching I tried this on the pihole itself

sudo ifconfig eth0 192.168.1.22 netmask 255.255.255.0 broadcast 192.168.1.255

It looked like it had set a static IP, but I saw that warning whenever I activated DHCP. I then tried this

sudo nmcli connection modify ethernet ipv4.gateway 192.168.1.1 ipv4.dns 192.168.1.1,8.8.8.8 ipv4.method manual ipv4.addresses 192.168.1.2

The issue persisted.

4

Using multiple networking tools for managing the same network interface may cause unexpected behaviour.

What's the output of:

sudo nmcli device show eth0 | grep IP4.ADDRESS
5

Okay, so I made the executive decision to try the following.

sudo ifconfig eth0 192.168.1.2/24 netmask 255.255.255.0 broadcast 192.168.1.255

This causes the following output:

sudo nmcli device show eth0 | grep IP4.ADDRESS
IP4.ADDRESS[1]: 192.168.1.2/24

Upon setting the PiHole as the DHCP server I seem to be getting every device connecting to it, and I'm not seeing any warnings relating to the DHCP IP addresses any more.

I want to ask those with more experience and knowledge whether the fact that I've already used both nmcli and ifconfig might cause issues in the future, given that it seems to be working now, or if I should just take the win and let it be until issues arise. Not sure if I need to undo (nor how I would) the changes on nmcli.

Other than that, I think this issue is resolved.

6

I can't answer that, as an answer would depend on your specific configuration of those tools as well as personal preferences, and may be others as well (systemd-networkd, netplan, ...).

But I can supply some general hints.

The most important one is that changes done via ifconfig are not persistent, so they won't survive a reboot. This would also mean that any potential conflicts won't survive a reboot, provided you've only used direct ifconfig commands as shared.

If you'd want them to persist, you'd have to make use of ifconfig's companion tools ifup/ifdown, which will read network configuration files.

Also, note that ifconfig is considered deprecated by many distributions, even if some of them still come with the containing net-tools package installed by default.

In general, ifconfig and NetworkManager would compete for configuring network interfaces, so in order to coexist, NM' commonly would ignore any interface defined in ifupdown's configuration file by default.

NM keeps its configuration under /etc/NetworkManager/, and it stores connection specific configurations in connection profiles, providing better support for machines connecting to different networks (like laptops) and/or multiple users on the same machine with different preferences.

There are quite a few UI tools allowing to manage NM on desktop systems, and NM's own nmtui is a CLI tool that allows interactive configuration.

While it would be possible to e.g. configure your ethernet interface via ifconfig/ifup/ifdown and manage your wireless connections via NetworkManager, it may be easier to have all your network configuration managed by one tool, so you only have to learn only one.

1 Like
7

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.