Can Pi-hole use hostnames, defined in DHCP settings, to identify clients in Dashboard or Querylog?

Can Pi-hole use hostnames, defined in DHCP settings, to identify clients in Dashboard or Querylog?

If Pi-hole is your DHCP I think this should work.

Unfortunately it doesn't work.
I use pi-hole as DNS-server and as DHCP-server, but in the daschboard and querylog most of the devices are shown as unknownxxx. Where xxx is the MAC-address.

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Dear jfb,
see here the token URL:
[✓] Your debug token is: https://tricorder.pi-hole.net/3p6XyKFv/

Seems to me, that nobody has an idea.

Seems to me, that the same question as;
(Client List and client activity)

I don't think so - there are no hostnames defined anywhere in that post, and there's no mention of Pi-hole's DHCP server.

It seems we missed your debug token - sorry for that.
Could you please provide a new one?
(I won't be able to personally take a look now, as I'm just about to log off, but other team members will do so).

So, next try.
Find Debug token here:
Your debug token is: https://tricorder.pi-hole.net/ziPSTHwl/

Regards

Just noticed this post. It does work where Pi-hole is the DHCP server. I went through a whole raft of DHCP reservations and gave clients their own hostnames (overriding whatever they may have presented). They are now referred to by those names in the Query Logs and on the Dashboard.

Actually some are working. Does it need some days(weeks) to show me the names, defined by me?
Do I have to click the trash or the other symbol in DHCP-Setting in section "Currently active DHCP leases"`?

The upper section "Currently active DHCP leases" shows either the names you have entered for them, or the names they are presenting if (or blank if none) if you have not entered a name for them.

The lower section "Static DHCP leases configuration" is where you can override a presented name and use your own. A quick way to get the client there is to find it in the upper section and click the orange icon to copy its details into the lower section. Then you can edit the hostname before saving it by clicking the green + button. You can only copy down or edit one host at a time. The hostname should be lowercase and user letters optionally with hyphens.

Note that if you use the blue Save button instead, that is only for the "DHCP Settings" section at the very top, so using that causes your hostname edit to be lost instead of saved. It took me a few moments to appreciate how this part of the interface worked.

To make the new hostnames start being used in the Query Logs and Dashboard, you can use Settings > System > Flush network table (and I also did Restart DNS resolver, not sure if that is techncally needed).

If you have given a client a hostname by reserving a lease this way, you can refer to it by that hostname on the network and it appears everywhere with that hostname in Pi-hole. Similarly if you are using the client's own presented hostname then that is how that client is referenced and appears.

Thank you for your hints and for explainng the orange button :slight_smile:

I have 19 entries in the "Static DHCP leases configuration"-section. Only three of the entries are visible in the Dashbord-"Client activity over last 24 hours"-section. Additionally this 3 Elements coming with the ending ".lan". "lan" is the "Pi-hole domain name" in "Advanced DHCP settings".
I did Flush network table and Restart DNS resolver.Now I see mainly the IP-Adresses in the Dashbord-"Client activity over last 24 hours"-section. So I think I have to wait until tumorrow.

A DHCP client that already had a lease through your router may hold on to that lease until its leasetime expires. That may be anything between a few hours or a few days, depending on your router configuration.

You could try to force a client to request a new lease by dis- and reconnecting it to your network, or by power-cycling it.

Your debug has a few Pi-hole diagnosis messages:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages
 count  last timestamp       type                  message                                                       blob1  blob2
 -----  -------------------  --------------------  ------------------------------------------------------------  -----  -----
 1      2023-02-26 03:38:53  ADLIST                https://ad11.adfarm1.adition.com                              31
 1      2023-02-25 09:17:13  ADLIST                https://gitlab.com/quidsup/notrack-blocklists/raw/master/not  25
                                                   rack-malware.txt
 1      2023-02-25 09:17:56  DNSMASQ_WARN          DHCP packet received on eth0 which has no address
 1      2023-02-27 21:37:19  DNSMASQ_WARN          no address range available for DHCP request via wlan0
 1      2023-02-26 18:03:04  DNSMASQ_WARN          Ignoring domain repeater for DHCP host name fritz
 1      2023-02-26 19:12:28  RATE_LIMIT            192.168.1.102                                                 1000   60

Those adlists may be outdated or not maintained any longer.
If those messages reappear regularly after gravity updates, you should consider removing them.

The DHCP messages may be related to your issue.
(As Pi-hole's UI warns you about diagnostic messages, it would have helped both you and us if you shared them earlier.)

Your Pi-hole's host has two network interfaces carrying a distinctive IPv4 address each, but they lie in different subnets:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] pl.kegypz.com is 0.0.0.0 on eth0 (192.168.1.222)
[✓] pl.kegypz.com is 0.0.0.0 on wlan0 (192.168.0.1)

Are those two subnets used intentionally?

Your Pi-hole's DHCP server is configured to serve IPs in the 192.168.1.x range, which may explain why there is no address range for requests arriving via wlan0.

The 'no address' warning for eth0 would indicate that your Pi-hole host system's network stack wasn't ready when Pi-hole started its DHCP server.
You may try to mitigate this by delaying Pi-hole's start via a DELAY_STARTUP entry in pihole-FTL.conf.

The log also shows that your .102 client has been rate limited.
What device does that IP belong to? Another router or other networking equipment, perhaps?

Thanks for going so deep into detail.

Pi-hole is working for a couple of weeks. So I think the router has no IP-Adress given to the devices now.

I will remove the adlists.

Yes, My intention was to have pihole as access-point when the router has its WiFi deactivated. But unfortunately It doesn't work. When the routers Wifi was OFF I got no connection to any device. So I thougt the wlan0 interface was off as well and I forgot the interface.
All the devices got an IP.adress in the the subnet 192.168.1.... So I don't understand how the interface wlan0 has an influence.
I will try to change the subnet of wlan0.

I will try to change the delay time

102 is just a laptop.

Regards

If you don't plan to reinitiate your access point endeavour, you could also disable wlan0 for the time being.

Could you provide a sample of your Dashboard or Query Log where a client is listed by IP instead of a name?

Please see the MAC-Addresses in the Dashboard:
image

Additionally I changed the IP-address of wlan0 to 192.168.1.2 in /etc/dhcpcd.conf and
I did Flush network table and Restart DNS resolver .
The result is that first there are only IP-addresses in the Dashboard, which chankge to MAC-addresses after a while.

Those are indeed hostnames for machines whose MAC addresses are unknown by Pi-hole's DHCP server.

Of the names appearing in your screenshot, at least one seems to be a from locally administered one, which would suggest the device in question would apply MAC address randomisation.
For most devices, you should be able to switch that off when connected to your home network (e.g. for Android, that woud be a privacy option for the specific wifi network).

If you are unsure what devices are behind those MACs, you may consider to restrict Pi-hole's DHCP server to only hand out leases to known devices as defined via its Static DHCP leases configuration.

To do so, create a custom dnsmasq configuration (e.g. /etc/dnsmasq.d/42-disallow-unknown-dhcp.conf) with the following content:

# disallow unknown host from acquiring a dhcp lease
dhcp-ignore=tag:!known

After running pihole restartdns, unknown devices wouldn't be able to join your network, which could help you identify them in order to reconfigure their MAC address randomisation for your network.

Once done, you may want to remove that file, or you may consider to keep that setting, to prevent unknown clients from acquiring a lease.