~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:02:94:34 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.180/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.227.5/24 brd 192.168.227.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::886d:aebe:1a5c:7b2b/64 scope link
valid_lft forever preferred_lft forever
root@JacoPi:~#
For whatever reason, there are two IP addresses assigned to the eth0 interface. Let’s see if we can find the configuration.
grep -Hn -A3 -B1 -E '(^|\s)eth0(\s|$)' /etc/network/interfaces /etc/network/interfaces.d/* 2>/dev/null
https://tricorder.pi-hole.net/42Mgpo6R/
I was able to generate a debug log (see above).
And this is what it spits out:
~# grep -Hn -A3 -B1 -E '(^|\s)eth0(\s|$)' /etc/network/interfaces /etc/network/interfaces.d/* 2>/dev/null
/etc/network/interfaces-8-# Ethernet
/etc/network/interfaces:9:allow-hotplug eth0
/etc/network/interfaces:10:iface eth0 inet dhcp
/etc/network/interfaces-11-address 192.168.0.180
/etc/network/interfaces-12-netmask 255.255.255.0
/etc/network/interfaces-13-gateway 192.168.0.180
I am not sure what is causing that second IP address. Thanks.
Linking the related topic on Pi-hole forum: PiHole stopped working after DietPi OS update interrupted - Help - Pi-hole Userspace
So something is assigning an additonal wrong IP address to the system and sometimes gets the default route as well, pointing to a non-existing host/IP.
Problem might be dhcpcd since ifupdown is used as well. First I thought a rogue DHCP server, but the flags shown in ip a do not look like it’s from a DCHP client. However purging dhcpcd is one step that makes sense in any case, then observing whether this IP keeps being assigned.
The debug log is from PiHole I guess. This we we are not able to access as it’s outside our domain.
Jep, was checked over at the Pi-hole forum.