The dummy interface on the Orange Pi Zero H2+ used to be the wireless antenna. It got disabled by the developers of the OS at one point due to it infamous performance issues.
Within /etc/dhcpcd.conf I have:
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
interface eth0
static ip_address=192.168.0.24/24
static routers=192.168.0.1
static domain_name_servers=127.0.0.1
Within /etc/network/interfaces I have:
# armbian-config created
source /etc/network/interfaces.d/*
# Local loopback
auto lo
iface lo inet loopback
# Interface eth0
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.24
netmask 24
gateway 192.168.0.1
dns-nameservers 8.8.8.8
The sudo brctl show command has nothing listed. I have never established any bridges.
What's weird is that if I run ifconfig -a the wlan0 interface is there and working. I have gone and disabled them via ifconfig wlan0 down and ifconfig dummy0 down, but they seem to reactivate upon reboot.
And /etc/network/interfaces should resemble below:
pi@noads:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
iface eth0 inet manual
When have corrected this and rebooted, check journalctl -u dhcpcd again if the routes get removed again ?
About the dummy0 interface, dhcpcd5 sees this interface and if not told otherwise, like done with the eth0 interface, its going to try acquire IP details via DHCP and IPv6 for the interface.
Try add below directive to the dhcpcd.conf file:
By the way, I reflashed the latest Armbian Strecth on the board and reinstalled Pi-Hole. I have since enabled the DHCP service on the Pi-Hole and the dhcpcd5 policy and dhcpcd.conf resemble yours.
However,
this looks a bit different for me. I don't have the comment on top and I only have the iface lo defined:
source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback
without the iface eth0. What you see above is the entire contents of my file.
A further fun discovery:
Once I enabled the DHCP on the Pi-Hole, I was able to restore my environment as it was before. The Pi-Hole now has individual queries for each device and is accessible via pi.hole/admin. However, it comes with a catch.
If I disable the DHCP on my router, my entire network dies, despite me having the DHCP enabled on the Pi-Hole.
I have also added my Pi-Hole's IP to the upstream DNS settings in the Settings tab (the "#53" was added automatically):
Why have you done this? Pi-Hole needs an upstream server to get DNS resolution, it cannot do this itself. By the time an upstream server is needed, Pi-Hole has already seen the request.
Any attempt to disable it, as instructed, has rendered my network unconnectable. I tried both with setting the checkmark on the router's DNS Server Config and putting the Pi-Hole's IP and without it. In both cases, after I disable the DHCP, everything crashes, no matter how many times I restart the router, the Orange Pi or the clients.
Having both DHCP services active is bound to cause troubles.
On the Windows PC, when you have Pi-hole DHCP enabled and the router DHCP disabled, try run below ones to renew DHCP lease (note time as you will need later when inspecting logs):
If renewing DHCP lease on the Windows client fails and dont have log entries, I suspect your router could be blocking something ... some safety feature, check router settings!
If DHCP renewal is successful, try run a DNS lookup on the Windows client:
nslookup pi.hole
And leave the router DNS settings on default (unchecked I suspect) when using Pi-hole for DHCP.
That way when Pi-hole dies, you only have to flip on DHCP on the router to fix.
As soon as I do this, I am locked out of everything. /renew doesn't work and I have to resort to resetting my router via the Reset key in the back. I cannot follow the rest of the instructions because of this.
I have tried looking at the router settings, as I have screenshotted in previous posts and there is absolutely nothing I can find that is worth to be changed.
I strongly suspect what DanSchaper suggested is true:
However, even if the router does do this, it is not an option exposed to me to toggle.
Still can't quite figure out how all I had to do before was change the custom DNS settings in my router before and it would work out of the box and NOW, I must enable Pi-Hole's DHCP and fight my router.
You have two different network managers/manglers running now that are probably conflicting:
pi@noads:~ $ apt show network-manager
[..]
Description: network management framework (daemon and userspace tools)
NetworkManager is a system network service that manages your network devices
and connections, attempting to keep active network connectivity when
available. It manages ethernet, WiFi, mobile broadband (WWAN), and PPPoE
devices, and provides VPN integration with a variety of different VPN
services.
.
This package provides the userspace daemons and a command line interface to
interact with NetworkManager.
.
Optional dependencies:
* ppp: Required for establishing dial-up connections (e.g. via GSM).
* dnsmasq-base/iptables: Required for creating Ad-hoc connections and
connection sharing.
address configuration.
* libteam-utils: Network Team driver allows multiple network interfaces to be
teamed together and act like a single one. This process is called "ethernet
bonding", "channel teaming" or "link aggregation".
pi@noads:~ $ apt show dhcpcd5
[..]
Description: DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
dhcpcd is a one stop network management daemon which includes
* RFC compliant DHCPv4 and DHCPv6 clients
* DHCPv6 Prefix Delegation support
* IPv4LL (aka ZeroConf) support
* ARP address conflict resolution
* Link carrier detection
* Wireless SSID profiles
* ARP ping profiles
EDIT: probably if you kill network-manager , it solves some of the issues like not being able to properly switch DHCP from router to Pi-hole.
I've been wondering, before I do that, should I change some setting somewhere (Pi-Hose or OS) so that the Pi-Hole knows to be discoverable at 192.168.0.24?
I'm thinking this becuase by default, it's using DHCP to for its IP, as the installer informers us during setup.
Currently dhcpcd5 tries to configure a static IP address to the eth0 interface, see tail /etc/dhcpcd.conf and journalctl -u dhcpcd.
And network-manager is configured to try acquire IP details via DHCP from the router for the eth0 interface:
You cant have both.
Pi-hole needs to be assigned a static IP especially if your activating its DHCP service and disable the router DHCP.
If the router DHCP is disabled, network-manager would not be able to acquire an IP for the eth0 interface.
It seems that disabling network-manager did the trick! It was indeed conflicting with dhcpcd5.
I have now enabled DHCP on the Pi-Hole and all my network devices have managed to get their IP leases from it. I am able to monitor their queries and successfully filter out ad content. I can also access the Web Interface via pi.hole/admin, too. Ideally, I would have continued using the router's DHCP service, as I wished to have as little burden as possible on the alreadly limited Orange Pi Zero, but it doesn't seem to be too heavy, anyway.
I still suspect there has been a change in router's firmware (that even the support employee didn't know about), but there's not much I can do about that.
I have marked your answer as the solution. THANK YOU very much for the constant support and thank you to everyone else who pitched in!
This thread has not only solved my problem, but it served as a rather educational exchange. For the knowledge shared and your time spent, I sincerely thank you all!
Its just a tiny little extra load.
Only when a device connects to network or when the DHCP lease expires (default 24 hours), they will contact Pi-hole to request a tiny little bit of info (IP etc).
Ps. Better mark below posting as a solution as it shows when you need to disable NM:
