Just updated to v4.3 and see no data in the network overview table. I use my physical router for DHCP not Pihole. Is this expected?
Not per se. I also use my router for DHCP and my devices show up. But only devices in the local network will show up. If you are running pihole on a remote server you will most likely see no devices. The same goes if you connect to your pihole with a VPN.
Pihole is running within a linux container. The container on my system use their own/different subset from the main network (lxc-net does this).
After a reboot of the container, the network overview table has 2 entries: another container (10.0.3.100) and 10.0.3.1.
- Clients from the 192.168.1.x network connect to pihole just fine.
- Pihole logs their DNS requests; they get allowed or denied based on my block lists.
- The top client table is populated with them.
BUT they don’t show up in the network overview. How does the network overview log clients?
it is all done through ARP iirc. If your containers are on a different subnet and cant SEE the clients then the network section would remain empty
As technicalpyro mentions it’s done via the Pi-hole ARP cache. Since the Pi-hole and the clients are on different logical segments with a routing application between them they would need some kind of forwarding application.
@technicalpyro - That is the case… nothing in 10.0.3.1 should be able to see the main network for security reasons. I also run openvpn in a container and I the 10.0.3.* subset segregated from the 192.168.1.* subnet.
@DanSchaper - I am ignorant to the type of traffic that would need to be forwarded for this to work. I could create a rule on my physical router to allow it just for pihole’s IP address if you could recommend what type of traffic (tcp/udp) and on that port it would flow.
I’m not sure if we can find a solution that would work. The way ARP finds clients on the segment is that a node wanting to find out who is on the segment will send a broadcast packet to MAC 00:00:00:00:00:00 and all nodes on the segment will respond with their MAC address to the requestor. That provides the requestor with all the MAC/IP pairs for all nodes on net.
In the case of an ARP proxy that would forward ARP requests across a network segment boundary the proxy sends all the IP addresses for the foreign segment but with the router/proxy’s MAC as the destination. So all the foreign IP addresses would have the same MAC address and not really provide any valuable information to display.
Thanks for explaining it… sounds like my setup will just not populate the network overview section without upstream modifications. Just curiously, what advantage does using the APR method you describe offer vs just pulling the info from the pi-hole.log or using whatever mechanism pihole uses to generate the top client list?
It will also show devices visible from the Pi-hole which do not use Pi-hole as DNS server. The logs will only contain clients that actively query the Pi-hole. It is mostly meant as a debugging or checking method that might revel, e.g., IoT devices that are present in your home network but bypass your Pi-hole as DNS server.
Please run the command
to get the ARP cache of the container. This is also what should be shown in your ARP table (note that FTL is doing some filtering on this data, only “meaningful” entries are used).
@DL6ER - Thank you for the info. If I run
arp the machine that hosts pihole’s container (it is 192.168.1.250), it looks like this:
% arp Address HWtype HWaddress Flags Mask Iface openvpn ether 00:11:2e:4f:36:6f C lxcbr0 _gateway ether b1:29:36:3a:a1:17 C eth0 ipad.lan ether 2a:2b:13:11:30:15 C eth0 pihole ether 00:11:2e:4f:36:5f C lxcbr0 living-room.lan ether 22:12:27:e2:ae:cf C eth0
When I ssh into the lxc running pihole and run it, it looks like this:
% arp Address HWtype HWaddress Flags Mask Iface _gateway ether 00:11:2e:00:00:00 C eth0
Okay, so this is expected. You can also enable ARP debugging in FTL by setting the appropriate flag to
After restarting FTL (
sudo pihole restartdns), ARP details should be logged every minute to
@DL6ER - What would enabling ARP debugging do in this use case? Just show it in the log?
Yes, none of the debug flags change anything. They just make the log (selectively) more verbose.