Why 'queries' table doesn't have mac address column?

fernandog · May 23, 2020, 2:39pm

IMHO queries table must have the mac adress columns as the main identification of the device instead of client (IP)

While using DHCP we lose the capability of investigate the device (mac address) that did a given request as it stores the client in the queries table. Client could be IP x.x.x.x today and tomorrow can be another.

Shouldn't mac address be used instead as its the main device identification?

Can someone explain why its designed that why?

jfb · May 23, 2020, 2:44pm

Are you using Pi-hole as the DHCP server, or another device on your network? If you are using Pi-hole, the DHCP is deterministic and will almost always keep the same IP assigned to the same client, even without reserved IP assignments.

See comment by DL6ER on this thread.

https://discourse.pi-hole.net/t/groups-and-dhcp/31901/5

fernandog · May 23, 2020, 2:47pm

Thanks, I will read that
I'm using router DHCP. No IP reservation.

Notice from this admin/network.php screenshot that two different devices had the same IP. I can't trace back which device did a given query

fernandog · May 23, 2020, 2:51pm

So, after reading that, if mac address is not possible, one possible solution is using the timestamp while tracing back queries from a given.

Am I'm wrong?

Found this. I'll wait

github.com/pi-hole/FTL

Allow defining clients by their MAC address

pi-hole:development ← pi-hole:new/mac_clients

opened 05:35PM - 13 May 20 UTC

DL6ER

+2464 -577

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- This PR teaches FTL how to use MAC addresses to automatically identify clients immediately connected you the Pi-hole. This will make the configuration for clients changing their addresses frequently (non-deterministic DHCP server, IPv6 privacy extension, non-constant ISP IPv6 prefixes, etc.) easier than before. Defining clients by IP addresses (possibly an entire subnet with CIDR notation) stays intact. It works the following way: If we didn't find an IP address match (either exact or subnet), we lookup the IP address within the Network overview table. If we find a (sufficiently recent) IP address match there, we extract the corresponding MAC address. We use this MAC address for a new lookup in the `client` database table to see if there is a client configured with this MAC address.

jfb · May 23, 2020, 3:28pm

Trying to trace requests back to MAC IDs is always going to be a workaround. The more reliable and controllable solution might be to ensure that your clients have consistent IP addresses. One way is to use Pi-hole as DHCP server. Not only will this likely keep the same address assigned to the same client, but it will also provide Pi-hole with the name of the client as well, which is easier than using an IP address to identify a client.

Another option is to reserve IP's for regular network clients. I find that this helps me manage my network more efficiently, as clients are stuck to the same address always. I reserve IPs for all regular network clients on the router. This lets me have consistent IP's for ssh connections, bookmarks, grouping of IP's by client type, etc. Even if you have quite a few network clients, you only have to set the reserved IP's one time and then you're done. Instead of seeing a MAC ID (which I can not easily correlate to a client), I see this consistently in all my Pi-holes:

For humans, names are much easier to remember than long strings of numbers, thus the entire concept of domain names instead of IP addresses in browsers.