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?
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.
Hmm... I've tried adding RESOLVE_IPV6=no to /etc/pihole/pihole-FTL.conf, then I used "pihole restartdns" and (just in case) "pihole arpflush". After a few hours of waiting my Pi-hole unfortunately still used IPv6 hostnames. However, it seems like it did stop resolving some IPv6 addresses because there were quite a few of them without hostname. Retried the above steps but with rebooting afterwards but it just won't work. It stills shows the transformed addresses. That's why I commented the above.
Maybe I should just wait until MAC addresses can be used for hostnames...
edit: now the queries page (not the network table) constantly shows the correct hostname for my iPhone, but not for my Windows machine. Maybe the network table just needs to update itself for the iPhone hostname to change. I'll keep waiting.
Thanks, it should work. You can check with grep "RESOLVE_IPV6" /var/log/pihole-FTL.log if the setting is used.
It looks like resolving IPv6 addresses is not disabled. grep "RESOLVE_IPV6" /var/log/pihole-FTL.log doesn't return anything and the log file only contains "WARNING: Hostname of client (paste IPv6 GUA) too long, truncating to 64 chars!" and "Resizing "/FTL-queries" from 2064384 to 2293760" and resizing DNS cache.
/etc/pihole/pihole-FTL.conf contains RESOLVE_IPV6=no and pihole restartdns was used after the modification.
By the way, my queries page decided to change back to an ISP IPv6 address as hostname for the iPhone.
update: I've rebooted the Pi and the log file now shows "RESOLVE_IPV6: Don't resolve IPv6 addresses" (as expected). However, the lines after the reboot process once again show "WARNING: Hostname of client (paste IPv6 GUA) too long, truncating to 64 chars!", which means FTL is resolving IPv6 addresses? What's happening?
Thanks, we actually have a bug here which made the option a bit useless. Please set
DEBUG_RESOLVER=true
as well to get the desired behavior.
This PR will fix it:
I've just added DEBUG_RESOLVER=true to pihole-FTL.conf and run pihole restartdns.
Pihole-FTL.log now shows
Trying to resolve <paste IPv6 address>
---> "" (configured to not resolve IPv6 host names)
As expected.
But it also shows
0 / 93 client host names resolved
0 / 4 upstream server host names resolved
The network table hasn't shown any changes regarding hostnames yet. Running "pihole arpflush" didn't change anything (well, it became blank for a moment and was suddenly filled up again). The query page doesn't show any changes either. Still the ISP IPv6 as hostname. I'll see whether anything has changed tomorrow.
This is not necessarily a problem as FTL tries to only resolve new clients and upstream servers every minute. Maybe it already knew everybody around so there was no need to resolve anyone here.
Hmm, yes, the cleaning will be a bit more difficult, maybe. You could do the following (but don't do it right now, keep on reading):
sudo service pihole-FTL stop
sudo sqlite3 /etc/pihole/pihole-FTL.db "DELETE FROM network;"
sudo sqlite3 /etc/pihole/pihole-FTL.db "DELETE FROM network_addresses;"
sudo service pihole-FTL start
These lines would ensure FTL does not try to obtain the host name from the database.
However, what you should do is trying my fix which I backported to v5.0 for you.
Run
pihole checkout ftl fix/broken_RESOLVE_settings_master
and agree that this is what you should do. After running the checkout, you can also remove DEBUG_RESOLVER. It will not be needed any longer. Just make sure to switch back to master before updating to v5.1 when this is released. But even if you forget about this, you will see that you cannot update to v5.1 so no drama will happen.
If my backported fix doesn't work for some reason, you can still try my cleaning commands from above.
I've run pihole checkout ftl fix/broken_RESOLVE_settings_master, removed DEBUG_RESOLVER from the FTL conf and restarted FTL. It works.
However, it's not really helpful. Because a lot of traffic is IPv6 (it looks like devices that also support IPv6 rather use IPv6 than IPv4), you'll end up with a Pi-hole that's messier than before, having a lot more seperate IPv6 compared to IPv4 addresses in the network table, making it harder to couple queries to devices. The "top clients" tables on the dashboard show almost only IPv6 addresses. Those addresses change from time to time. That's a downward step compared to having all of a device its addresses assigned to an ISP IPv6 address hostname. Once again, I'll give it some time and see if my view on this matter changes. Ofcourse, if I'd like to, I could go back to the way it used to be at any time.
Furthermore, I would like to emphasize that coupling MAC addresses to hostnames and using this as a way to create a clear network table sounds like a great idea. I've read that it's currently an experimental feature, but I'm not sure when it's expected to be released and whether this new feature will solve this problem. I hope you can clarify this.
edit: I noticed that OP had this issue where clients have exactly the same hostname, whereas my ISP processes an IPv6 address into the ISP address (for example 2001-1c00-0000-0000-0000-0000-0000-0000.cable.dynamic.v6.ziggo.nl).
moreover, this error appeared in the FTL log 6 times over a period of 3 minutes:
ERROR: SQL query "END TRANSACTION" failed: database is locked
END TRANSACTION failed when trying to store queries to long-term database
Keeping queries in memory for later new attempt
followed by the following notice:
Notice: Queries stored in long-term database: 101 (took 1590575366144.0 ms, last SQLite ID 1270953)
Queries from earlier attempt(s) stored successfully
This doesn't look like something to worry about but I'm posting it nonetheless.