DHCP issues on router Huawei EchoLife EG8145V5

Expected Behaviour:

.
The Pi hole must lease an IP from the rate 192.168.100.200 - 192.168.100.251 on my home devices since I disabled DHCP Server for IPv4 and IPv6 on my router, enable the IPv4 and IPv6 DHCP Server on PiHole

Actual Behaviour:

My home devices are unable to obtain an ip

Debug Token:

https://tricorder.pi-hole.net/Xi2EsV1f/

The DHCP server part of the debug seems to be good.
The interface configured for my pihole is the wlan0, the ip is static, and the router ip is the same on dhcp and the actual router ip: 192.168.100.1

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)

   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds

   * Received 300 bytes from wlan0:192.168.100.68
     Offered IP address: 192.168.100.245
     Server IP address: 192.168.100.68
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.100.68
      lease-time: 86400 ( 1d )
      renewal-time: 43200 ( 12h )
      rebinding-time: 75600 ( 21h )
      netmask: 255.255.255.0
      broadcast: 192.168.100.255
      dns-server: 192.168.100.68
      domain-name: "lan"
      router: 192.168.100.1
      --- end of options ---

   DHCP packets received on interface lo: 0
   DHCP packets received on interface eth0: 0
   DHCP packets received on interface wlan0: 1

#DHCP logs:

Jan 22 03:18:53 dnsmasq[20607]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no
-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 22 03:18:53 dnsmasq-dhcp[20607]: DHCP, IP range 192.168.100.2 -- 192.168.100.251, lease time 1d
Jan 22 03:18:53 dnsmasq-dhcp[20607]: DHCPv6 stateless on wlan0
Jan 22 03:18:53 dnsmasq-dhcp[20607]: DHCPv4-derived IPv6 names on wlan0
Jan 22 03:18:53 dnsmasq-dhcp[20607]: DHCPv6 stateless on 2806:2f0:4021:a742::, constructed for wlan0
Jan 22 03:18:53 dnsmasq-dhcp[20607]: DHCPv4-derived IPv6 names on 2806:2f0:4021:a742::, constructed for wlan0
[...]

##Also i tried:
Repair pihole (pihole -r "repair option")

SOLUTION: Since my router Huawei EchoLife EG8145V5 is forming a barrier for broadcast packets that are being sent from the clients with the initial DHCPDISCOVER , i change my Pi from wireless to wired.

I enable verbose login on my Android wifi connections and seems to be a failure on the dhcp configuration
"Network Selection Disabled DHCP FAILURE = 1"

Maybe sniffing dhcp packers with my Android that also is on the same LAN brings me more clarity.

How does your Android client connect to your network?
Would that involve any additional network equipment beside your router?

Your debug log shows thast Pi-hole's DHCP server does correctly supply a DHCP lease upon receiving a client's DHPC broadcast for one:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds

* Received 300 bytes from wlan0:192.168.100.68
Offered IP address: 192.168.100.245

Note that broadcasts are same-link only. A different link/network segment client's broadcast would never reach your Pi-hole.

Monitor and search your pihole.log for your clients DHCP requests:

sudo grep DHCP /var/log/pihole/pihole.log

Do your Android's DHCPREQUESTs register there?
Please share the output for such a DHCP negotiation.

Hello Bucking_Horn, thank you for your reply.

I reviewed your answare twice to figure out more about the possible solutions.
My answares:

How does your Android client connect to your network?

Throught wireless. My Router haves two AP, one for 2.4Ghz and another one for 5.0GHz.
Both are the same subnet, the same configuration

Would that involve any additional network equipment beside your router?

No, theres no any additional network equiment beside my router and the Pihole that i want to deploy.
In fact, the network is as simple as this:

Do your Android's DHCPREQUESTs register there?

I can't see any Andorid request on my logs, since the Android is trying to obtain an ip without any success:

Jan 23 17:46:37 dnsmasq[51935]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 23 17:46:37 dnsmasq-dhcp[51935]: DHCP, IP range 192.168.100.200 -- 192.168.100.251, lease time 1d
Jan 23 17:46:37 dnsmasq-dhcp[51935]: DHCPv6 stateless on wlan0
Jan 23 17:46:37 dnsmasq-dhcp[51935]: DHCPv4-derived IPv6 names on wlan0
Jan 23 17:46:37 dnsmasq-dhcp[51935]: DHCPv6 stateless on 2806:2f0:4021:a742::, constructed for wlan0
Jan 23 17:46:37 dnsmasq-dhcp[51935]: DHCPv4-derived IPv6 names on 2806:2f0:4021:a742::, constructed for wlan0
Jan 23 17:56:19 dnsmasq[621]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 23 17:56:19 dnsmasq-dhcp[621]: DHCP, IP range 192.168.100.200 -- 192.168.100.251, lease time 1d
Jan 23 17:56:19 dnsmasq-dhcp[621]: DHCPv6 stateless on wlan0
Jan 23 17:56:19 dnsmasq-dhcp[621]: DHCPv4-derived IPv6 names on wlan0
Jan 23 17:56:30 dnsmasq-dhcp[621]: DHCPv6 stateless on 2806:2f0:4040:19b6::, constructed for wlan0
Jan 23 17:56:30 dnsmasq-dhcp[621]: DHCPv4-derived IPv6 names on 2806:2f0:4040:19b6::, constructed for wlan0
Jan 23 17:56:30 dnsmasq-dhcp[621]: DHCPINFORMATION-REQUEST(wlan0) 00:01:00:01:2a:be:93:89:dc:a6:32:01:51:85 CerberusPi
Jan 26 12:25:14 dnsmasq[7274]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 26 12:25:14 dnsmasq-dhcp[7274]: DHCP, IP range 192.168.100.200 -- 192.168.100.251, lease time 1d
Jan 26 12:25:26 dnsmasq[7425]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 26 12:25:26 dnsmasq-dhcp[7425]: DHCP, IP range 192.168.100.200 -- 192.168.100.251, lease time 1d
Jan 26 16:19:10 dnsmasq[9573]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 26 16:19:10 dnsmasq-dhcp[9573]: DHCP, IP range 192.168.100.200 -- 192.168.100.255, lease time 1d
Jan 26 16:20:47 dnsmasq[9678]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n IDN DHCP DHCPv6 Lua TFTP no-conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jan 26 16:20:47 dnsmasq-dhcp[9678]: DHCP, IP range 192.168.100.200 -- 192.168.100.254, lease time 1d

A client would initiate DHCP negotiation with an attempt to discover DHCP servers on its link by broadcasting a DHCPDISCOVER.

If your Android is issuing those broadcasts, then they do not make it to your Pi-hole:
Your log shows your Pi-hole has not received a single DHCPDISCOVER.

If it woud have been, you'd have observed lines like:

dnsmasq-dhcp[485]: DHCPDISCOVER(wlan0) b8:27:ba:dc:0f:fe

followed by something like:

dnsmasq-dhcp[485]: DHCPOFFER(wlan0) 192.168.1.32 b8:27:ba:dc:0f:fe
dnsmasq-dhcp[485]: DHCPREQUEST(wlan0) 192.168.1.32 b8:27:ba:dc:0f:fe
dnsmasq-dhcp[485]: DHCPACK(wlan0) 192.168.127.32 b8:27:ba:dc:0f:fe phono-pi

Some routers would isolate wifi clients from each other by default, allowing them only to access the Internet, while preventing communicaton to other wifi or even all locally connected devices.

Does your router have such an option?
Providing your router's make and model may help attract users with similar h/w who may be able to share their knowledge.

Hello again Bucking_Horn.
I was off for computers due to medical issues.

Here are my answares:

My Router device is a Huawei EchoLife EG8145V5, unfortunally, the official documentation is blocked by the vendor but is this one:

ONT tipo enrutador inteligente EchoLife EG8145V5 | Huawei Enterprise

Just navigating throught the web portal of the Router, the mentioned wifi isolation is not present.

I also tried with a different device (an Iphone) and is the same issue.
The logs did not shown anything this time, by using this command:

sudo grep DHCP /var/log/pihole/pihole.log

I am thinking serously about mounting a router by myself with openwrt or similar on an another raspberrypi aside the pihole, or buy a new router with more permission at my disposition, since the router I have at home is disabled the option of set the DNS address propagation, presumably by my ISP.
Making network segmentation for visitors and mount the dhcp in there.

On what is Pi-hole running?
Is it bare metal, VM or maybe in Docker?

Could be a firewall on the Pi-hole host.
For older distros to list rules:

sudo iptables -nL

For newer ones:

sudo nft list ruleset

Hello deHakkelaar, thanks for your reply

My pihole is on a Raspbery-pi wired to my router, there is no iptables rules because the installation was the default.

Chain INPUT (policy ACCEPT)
target prot opt source destination

Today, I decide to sniff my network, focused on the DHCP requests.
The DHCP is working now by pure magic, the only thing I do different is reset the pi, and wired it by Ethernet
(The first time i tried, it was wirelessly with the Wi-Fi boundle installed by fabric on the Pi)

I just have a final question:
All my devices connected to the Pi by DHCP, is obtaining the DNS address: 192.168.100.70, since the Pi-hole haves the IP 192.168.100.68 I dont know if this is intended.

1 Like

No its not.
Check the own IP for the Raspi with below:

ip -br -4 address show

Or:

dhcpcd -U eth0

Check if it matches the dns-server IP advertised via DHCP with below:

pihole-FTL dhcp-discover

If they dont match, run below and select reconfigure:

pihole -r

About it not working when connected via WiFi, this sounds like @Bucking_Horn was trying to explain, somehow the AP part of your router forming a barrier for broadcast packets that are being sent from the clients with the initial DHCPDISCOVER.
Anything that gets router, NATed or Vlan's forms a boundary to the broadcast domain.

If you install tcpdump with below:

sudo apt install tcpdump

you can inspect those packets destined for the broadcast IP 255.255.255.255 that are being received when a client without IP 0.0.0.0 joins your network:

pi@ph5a:~ $ sudo tcpdump -nti any udp port 67
[..]
IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 0c:2f:b0:XX:XX:XX, length 308
IP 10.0.0.2.67 > 10.0.0.143.68: BOOTP/DHCP, Reply, length 312

The first line is the broadcast and the second line is the reply in unicast.

Hello again deHakkelaar,
I do the comparision, my own IPs for the Pi are:

azurebit@CerberusPi:~ $ ip -br -4 address show
lo               UNKNOWN        127.0.0.1/8
eth0             UP             192.168.100.70/24
wlan0            UP             192.168.100.68/24

And the IP advertised via DHCP are:

  • For Ethernet:
* Received 300 bytes from eth0:192.168.100.70
  Offered IP address: 192.168.100.203
  Server IP address: 192.168.100.70
[...]
 dns-server: 192.168.100.70
  • For Wi-Fi:
* Received 300 bytes from wlan0:192.168.100.68
  Offered IP address: 192.168.100.204
  Server IP address: 192.168.100.68
[...]
   dns-server: 192.168.100.68

Those perfectly match.

And with the TCP Dump:

azurebit@CerberusPi:~ $ sudo tcpdump -nti any udp port 67
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
eth0  B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 36:b7:d3:1a:f1:5d, length 300
eth0  Out IP 192.168.100.70.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
wlan0 B   IP 192.168.100.70.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

I think that the PI is tryng to lease IPs from wlan0 and eth0 interfaces.
All is work perfectly fine now.

Now, I'm curious about this. How can I probe that my ISP router is blocking the broadcast packets?
If I can probe it, maybe we can write a warning or a list of Routers that haves this issues with the Wi-Fi.
This for the future users...

I believe you've provided evidence for that already with below:

The first packet shows a device/client with a randomized MAC 36:b7:d3:1a:f1:5d trying to obtain a lease via a DHCPDISCOVER broadcast.
But its only being received on the eth0 interface and not on the wlan0 interface.
If wired and Wifi were the same network segment, you would expect to receive the DHCPDISCOVER broadcast on both interfaces.

I believe you've provided your own solution by connecting the Raspi via both wired and Wifi :wink:

1 Like

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