Incorrect Hostnames

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

The dashboard should display individual client hostnames for each user, as I am using Pihole as my DCHP server with the router's own DCHP server disabled.
Using Raspberry Pi 1 Model B, running Pihole 5.0.

Actual Behaviour:

The dashboard lists any client using ipv6 to access the network as 'broadband.bt.com'. (see image). This is repeated into the network overview, which seemingly places 'broadband.bt.com' over the device's 'true' hostname (see image), despite this being visible within the DHCP config on the web interface (see image).



Debug Token:

https://tricorder.pi-hole.net/pkom1orb8d

The network table uses the most recent hostname, and if new IPv6 addresses are being created and assigned via the router, then this is what the network table sees.

If you have the ability with your router, disable IPv6 and see if the problem resolves.

Sadly I do not have that ability - my ISP-provided router will not let me turn ipv6 off at all -the only configuration options relating to ipv6 are in the below image.

Can't you look up the hostname by using the IPv4 address instead of using the most recent hostname found via IPv6? This way the network table would function as wished thus users won't experience the inconvenience.

Edit: to be clear,
using

dig @(local IP Pi-hole) -x (local IPv4 client) +short

instead of using IPv6:

dig @(local IP Pi-hole) -x (local IPv6 client) +short

returns the hostname users expect to see.

The issue is known and worked on, see this topic (again broadband.bt.com):

I don't quite know what this means at all - I'm completely blind to code and everything like this!

Thank you! How would I be able to access that new 'add support for multiple hostnames' feature? Again, I'm blind to code and don't quite understand all this!

It's part of the new/mac_clients branch, see here. Please not this branch is still under development and can break things and should be considered as "testing".

Another approach might be to disable IPv6 resolution on pihole.

The referenced experimental feature will likely make it only into Pi-hole v5.2 as a lot of additional things may need to get sorted out.

So the issue is that were sourcing host names from the database when there are none or that the IPv6 names overwrite the IPv4 names?

If the former, then we can add a feature to disable this via a config setting for v5.1. If the latter, then @yubiuser's suggestion seems to be the answer here.

Thank you both - and apologies for my unique, annoying network setup. I've moved onto the mentioned testing new/mac_clients branch for now - and will probably be there until the update moves onto master. I'll check if it offers any sort of solution. The issue was that the generic 'broadband.bt.com' was being used as a hostname for any device using IPv6, rather than the 'true', IPv4 device name - effectively overwriting it as you say.

Does this approach only affect the network table (and not the way queries normally work)? Is it just to make Pi-hole resolve hostnames only over IPv4?

Yes, that's how I understand

https://docs.pi-hole.net/ftldns/configfile/#resolve_ipv6

Apparently the issue with using RESOLVE_IPV6=no is that you end up having a network table with a lot of IPv6 adresses without hostname, which is something I cant imagine anyone wants...

Well, a lot of people seem to don't want the IPv6 host names. This is why we added this option. For instance, many German users receive host names for their IPv6 devices like p200300DA9BBF17FA0000000000000001.dip0.t-ipconnect.de which is their devices IPv6 address transformed into some more or less (rather less...) useful name. I can feel why they want to avoid this.

Doesn't sound bad to have the option to disable this, so here we go:

@tomco I'm interested in your thoughts, we should probably open a new discussion when you have suggestions for improving the new/mac_clients branch. It is more thought for v5.2, not earlier as there are some more things to get done and I don't want have it sitting as a possible blocker for an intermediate v5.1 release.