I’ve some clients that are on a different subnet/VLANs than my pihole. They can use use pihole without any issues, but are not displayed in the network overview.
What you see is normal, at least for the current v4 version.
To my last knowlegde, Pi-hole is populating its Network overview from the system’s ARP cache.
As that will only ever hold entries for devices on the same network segment, you won’t see specific devices behind another router, L3 switch or the like.
You may want to confirm this by a developer like @DL6ER. He might also be able to tell whether it’s planned to expand on this with any future release.
Thanks for the reply, I suspected something like this.
With the coming v5 including Group Management/Clients and a prepopulated list with known clients (also missing there, probably because info is extracted from ARP cache as well) it feels like something is missing if not all clients are shown.
Maybe a combination of ARP cache and IPs from clients querying pihole could be a solution?
Confirmed. Nothing really to add here (it’s from the
neigh cache, not
arp, but that’s minor technical details).
The network table identifies devices by their hardware address (a.k.a. MAC address). As a device can have multiple IP addresses, they are all stored only as mere pointers to a physical device. The table is currently not able to store devices for which the unique quantifier is missing. Without the MAC address, Pi-hole has no chance to identify if an IP address belongs to the same device when a non-deterministic DHCP server (most actually are non-deterministic!) decides to hand out a different address to one and the same client on another day. Should we store them all for all time?..
The network table started out as something different: A mere diagnosis tool to identify if there are devices in your local network that are visible to the Pi-hole but never ask the Pi-hole any questions. This to spot possible misconfigurations. Obviously, this simple debug tool had simple networks in mind. A network with VLANs is absolutely not part of the category “simple”.
I will think about a possible way of realizing this. I don’t know how to do it right now without scarifying foreign key constraints in the database.
Are they not one and the same ?
Part of the iproute2 command suite, ip neighbor provides a command line interface to display the neighbor table (ARP cache), insert permanent entries, remove specific entries and remove a large number of entries.
No. I have no reference at hand right now, but the main difference is that the
neigh protocol supports IPv4 and IPv6 whereas
ARP itself is IPv4-only.
Thanks for the explanation.
How is the Group Management/Clients handled internally? If I set up groups/domains/adlists for a specific client I do it via web GUI displaying IPs. But with the possibility of changing IPs (by DHCP) you would need to store (and use) the MAC internally instead of the IP to identify a client and apply the right rules. Otherwise you would not be sure that the same physical device rules were created today will be applied tomorrow…
Suggestion to the issue, assuming someone with a “not-simple” network setup should know how to set static IPs or fixed DHCP leases:
For clients on the same subnet don’t change anything. But add clients making requests to pihole in the network overview (even though you don’t have the MAC - write “N/A different VLAN/subnet”) and add the ability to delete them (similar as someone requested here).
In the Group Management/Clients show them in the drop down list as well, but separate them from the ones from the neigh cache (e.g. horizontal line) and add a statement that static ip/fixed DHCP should be used for these devices.
Great things for a Feature Request, the community can vote on the utility of it.
Moved to Feature Request and changed the title.
DNS-side everything is decided based on the IP address.
Yes, this is a potential issue, however, I do not want to entangle the network table too much into normal DNS operations. We’ve discussed various use-cases before starting the implementation and it turned out that configuring IPs seems to be advantageous over configuring devices. Especially since we cannot identify devices outside of the local (logical) network. Furthermore, one and the same device might have multiple (virtual) interfaces, all belonging to the same MAC, however, they might be associated to various virtual machines on said device and you may want different blocking rules for them.
The issue of non-deterministic IP addresses is better solved by flipping over to a deterministic DHCP server. And as Pi-hole even ships one, there seems to be little need to complicate things trying to compensate the drawbacks of non-deterministic DHCP servers.
This requires a major restructuring. Currently, there is no IP allowed to exist without a MAC address.
Don’t get me wrong I love this idea.
I have 3 vlans myself.
I personally don’t think all the work warrants the small reward on this one.