Yes, this is a nice summary of why it is not there.
Each client sending requests to Pi-hole gets a distinct record in the memory. For the DNS server, IP addresses are the only thing it see. It is how it identifies a "client". Also because it is an IP address which is expecting the reply to the question. If we'd record clients in the sense of hardware with one MAC address, maybe even two (WiFi, Ethernet) or more, we'd also have to store the addresses plus which address of the client a request came from. It would require a fundamental rewrite of a lot of code for yet low gain in the end.
We added a lot of improvements to how clients can be recognized in this thread and I appreciate all the testing, comments and suggestions. It brought us very far in improving how Pi-hole recognizes clients. You can now use a MAC address to apply the per-client filtering to entire devices (as in: network adapters).
Now, looking at how we can get to what was asked by @Robert_D_Marriott, I had the idea of a new concept: super-clients
They would be (in some way) ordinary clients, so appear everywhere on the dashboard just like the other clients, but they don't really exist. They are purely virtual. Let me give an example of what I have in mind:
In this example, we have the following "clients" (in the sense of IP addresses):
ID
IP address
MAC address (simplified)
host name
total queries
blocked queries
0
192.168.1.25
AA
linux-box-1
111
34
1
fe80::ca9c:1203:5365:010a
AA
some-very-long-name-isp.com
200
44
2
2a02:3443:3307:5968::1
AA
other-very-long-name.isp.com
968
455
3
192.168.1.22
BB
linux-box-2
134
22
4
192.168.1.20
CC
android-phone
334
23
We define a super-client like
ID
MAC address (simplified)
host name
0
AA
linux-box-1
The super-client will take over all the MAC address AA clients, so the output on the dashboard would look like
ID
IP address
MAC address (simplified)
host name
total queries
blocked queries
--
---
AA
linux-box-1
1279
533
3
192.168.1.22
BB
linux-box-2
134
22
4
192.168.1.20
CC
android-phone
334
23
This will be another big change and definitely needs to be discussed outside of this current discussion.
Looks great and would make a lot of users happy. If seen some requests for grouping for stats (especially with many IPv6 addresses for the same client).
Agreed that this will be a much appreciated feature as home and small business networks move to IPv6. I appreciate the complexity, but figure I would through the idea in to the mix.
I don’t know why my devices are changing so often. I don’t have the privacy setting on on any of my clients (all Apple) unless their has been a recent change to turn it on by default that I am not aware of. That will require some digging. It’s not all clients on my network, but it is some of my most active. Definitely not an issue for this thread.
Yeah, I don't have any Apple devices myself, I'm Linux-only - good for the money Joke aside, I've seen users mentioning that there was a recent Apple change concerning randomizing MAC addresses (which will likely randomize IPv6 addresses as well?). Maybe this affects you. Please open a new ticket for it and/or use the search on this forum to find more details.
Due to the merge into development, the branch new/mac_clients picked up the new/tre-regex changes as well now. So if you update your new/mac_clients branch, you can already test both changes in combination (plus also the ECS (EDNS Client Subnet) identification if you can use that). I had to fix quite a number of merge conflicts, however, our automated test suite suggests that everything works well.
No, these are all experimental changes. None of these two features are in the released version. However, these features appear to be stable so testing them is possible without causing harm (probably).
Well, actually, yes. I implemented a first attempt at what I described above already yesterday, however, I haven't really had any time for testing. I did the testing now and everything seems to work as expected. I will document this and we should discuss this in a new topic:
Another (bigger*) update to this branch is parsing of the kernel's Internet protocol address management. Local interfaces are not included in the ARP/neigh cache and, hence, they were recorded as individual mock devices without being able to stitch them together. This is now resolved.
Before (individual mock-devices without a connection to each other):
Now (they are grouped to the same device):
This will also work for any other local interface on the Pi-hole, e.g.,
[✓] Detected ARM-aarch64 architecture
[i] Checking for existing FTL binary...
[i] Checksums do not match, downloading from ftl.pi-hole.net.
[i] Downloading and Installing FTL...pihole-FTL-aarch64-linux-gnu: FAILED
sha1sum: WARNING: 1 computed checksum did NOT match
[✗] Downloading and Installing FTL
Error: Download of https://ftl.pi-hole.net/new/mac_clients/pihole-FTL-aarch64-linux-gnu failed (checksum error)
[✗] FTL Engine not installed
Unable to complete update, please contact Pi-hole Support
Thanks @DL6ER for merging into development, great work!
I've checked out development, most of it seems to work.
Now Network Table shows "unknown" for every device. I've flushed table but also after one hour no hostname are shown.
Edit: Thanks @yubiuser for your input in the next post, that was my problem. I thought ftl and web are merged, so I switched to development. But web isnt merged yet. That's it! Wait for web to get merged also.
Joke aside, I've seen users mentioning that there was a recent Apple change concerning randomizing MAC addresses (which will likely randomize IPv6 addresses as well?). Maybe this affects you. Please open a new ticket for it and/or use the search on this forum to find more details.
