Chrome 81, FF 76
Just a weird idea: can you extend the code to specify devices by hostname? Then users would be able to use client-> groups also via VPN/VLAN etc. with non-deterministic DHCPs.....
Good idea, done.
Small glitch, already fixed. Please update.
I'll check this out when I'm back home (takes a few days).
Well, it's not that weird at all. I was toying with the idea of doing this. However, it is a quite fundamental change (again) and extra code that would need to be written (again). I'll be busy for some time, but I will keep thinking about it. Currently, I see no harm in this idea. It just gives users even more flexibility. They can decide if they want to use it - or not.
Fixed.
Thanks.
Puh... 
Well, after having consulted my pillow, I recall why I haven't added it, so far. It will not work as you may expect it to. I will (superficially) go into the technical details involved here.
Example 1 - The client is already present in the network for a longer time before doing its first lookup
When there is an entry in the network table with MAC, IP and host name, everything would work as expected. We can look up the IP address of the incoming request, relate this to a MAC address and check if one of the host names associated with this MAC is a configured client. If so, take the groups defined here. 
However, I think this scenario will happen only rarely.
Example 2 - The client immediately performs a lookup when connecting to the network
There is may be no network table entry, so far. Chances are high that there isn't even a (complete) ARP/neigh entry when the device freshly joined the network, so FTL can only see its IP address.
Neither MAC nor host name will be available at this point and I don't think there's something we can really do about this. Hence, if a client is configured through MAC or host names, we will miss the configuration at this point and (wrongfully) attribute it to the default group.
We can "compensate" for the miss by triggering a re-grouping inside FTL when we are able to gather information about the client. However, this still means that a client would be able to do lookups it should not do (because usually blocked by, e.g., gravity) for some (short but maybe up to one minute) period of time. I don't think this is good.
And, before you ask, we can neither do a lookup for the host name when we first see a client appearing. The reason for this is that we are already processing an incoming query (said client is asking the DNS server something). FTLis now processing and trying to find out what to do with this client (to to reply may depend on the assigned groups). Unfortunately, we cannot run concurrent queries when we're still in this incoming query. Hence we cannot make lookups for hostnames while we're still in the loop of processing a running query (the DNS infrastructure is locked).
Seems to be a wise pillow.
Yes, I still remember:
As you said, this is the same limitation for MAC and hostname - which doesn't speak against implementing the hostname approach when MAC is implemented.
For both pihole needs to
As the network table is updated every minute you could trigger a "re-groupping" immediately afterwards. This would also compensate for
I agree from a technical point of view - from a user's point of view I don't care. When I had no pihole all devices could contact whatever they wanted. I would rather have this trade-off (small amount of time wrongly assigned clients) than to miss this feature. I know you want pihole to be perfect - I guess for most it is sufficient when it is really good.
This is still a complex task to do because we have to communicate this through forks as well when there are TCP requests. It is by no means trivial, except for when we do this once per minute for every client.
It is not quite that, they are not necessarily able to contact whatever they want. They will still be member of the default group so whether gravity and which parts of the black and whitelist will apply for them depends on the individual user configuration.
Yes, I want things to work perfect. Anything else will trigger support requests and is hard to explain. We would, at least, have to put up a warning like: Note that MAC and host name client recognition may involve a certain delay and not be available instantaneously after connecting your devices.
Something along these lines.
However, I fee the need for more feedback also from others how this could get realized. And I'm interested both in technical as well as user point of views of this.
This is what I imagined. Would that create to much overhead to do it for all clients? But it might be less complex code to maintain.
Would be wise to put up that warning at the clients page.
I already try to invite users to this topic if they ask for that feature. Hopefully they will give some feedback as well.
I see no need to rush this feature... if it makes it to 5.2 or 5.3 is soon enough.
I am currently testing, I am in need of something like this as my Network rotates ipv6 address assignment constantly.
So Far, I am running into no problems, I did get a SQlite error when flushing the network table. seemed Minor though because everything appears to be working.
I am seeing this behavior as well. I am using Safari on OS X.
Unrelated to the MAC changes, but it appears that the theme settings are not saving for me (choosing light or dark). It changes when I hit save, but as soon as I navigate away, it reverts back to light theme. And if I go back to the settings, it is back on the default light setting.
I checked the settings conf file, and I don't see an entry being created for the theme settings. Changing the boxed layout works, and updates settings as expected. So it seems it is just the theme setting that isn't saving.
I ran into this problem while adding clients, I was at about 50 or so clients and a big red message popped up saying 1 of 0 Unique ID's, and FTL went down entirely. I had to restart it. After restarting the issue went away.
Also got this error.
root@raspberrypi:~# pihole restartdns reload-lists
[✗] kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
Other than what I just mentioned, I am currently running 68 clients linked by mac address (Pihole not acting as DHCP, instead conditional forwarding to the router with router handing out Pihole as acting lan DNS). All clients working properly with list respective list assigned to each one.
Would be good to post the error here so it can be fixed.
I see that too. It worked for a while but no it doesn't anymore. I also had it before using the current development branch
Tried switching back to
pihole checkout ftl development or master
but DNS resolution stopped after a few seconds.
[2020-05-17 16:26:00.228 4073] SQLite3 message: no such column: name in "SELECT name FROM network WHERE id = (SELECT network_id FROM network_addresses WHERE ip = ?);" (1)
[2020-05-17 16:26:00.228 4073] getDatabaseHostname("10.0.10.64") - SQL error prepare: SQL logic error
Switching to this branch and DNS resolution is restored.
new/mac_clients is not compatible with master or development, once you changed to new you committed to it.
Edit: Unless you delete the database used in new/mac_clients and restore from a backup or create a new one.
Thanks for the explanation.
You can go back.
Here are the steps that worked for me.
First I removed all mac listed clients off of my Clients List.
Then I used
pihole checkout master
This is where i noticed after the update
pihole would not start.
Then I edited /etc/resolv.conf and added
Nameserver 8.8.8.8
I used Pihole option
pihole -r
Then I ran
pihole arpflush
followed by
pihole flush
After pihole flush the pihole was up and running!
I did all of this with out having to use my backup.
Pihole is very resilient at repairing itself.
When you are done remove the arbitrary Nameserver from /etc/resolv.conf or reboot it will remove itself.
Thanks for the workaround. I have no need to switch branches so I stick with the current.
I switched to using this on one of my other pi's. It seemed to me to use a little bit more memory than the initial 5.0 master branch, so I am running it on a faster pi. Did you experience any extra memory/cpu constraints using the mac_clients?