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.
This is nothing to worry about - it was implemented to prevent FTL from failing if the long-term database is locked. As you see it was later successful in storing them.
It is still in development and scheduled for v5.2 as far as I understood. I and others using it without problems in daily use but of course bugs can still occur.
This is expected. IPv6 is "better" than IPv4 and meant to replace the latter, hence, it only makes sense to prefer it if it is available.
I this different from before?
Why? Do you maybe have IPv6 privacy extensions enabled with aggressive settings?
I use it too, however, I agree that it should be done only when DNS fails are acceptable and you do not get killed by family members because mum killed the WiFi (again) 
Well, it has never failed for me, but the developers said that it is an experimental feature so it could fail at some point. And, as the network database is modified, there's also no way back (well, you have to start with an empty/old long-term database if you want to go back).
The network table itself does not change due to this, devices are already only one row in here and all matching IP addresses are added to them. What do you want to see here, exactly?
Otherwise, I agree with what has been said by others since you asked your question.
Simply said, the ideal situation would be to have OP’s screenshot of his network table but with the correct hostname and not some kind of ISP address.
Disabling IPv6 is not something I take as an answer. Using RESOLVE_IPV6=0 was to deal with this problem in some way, but doesn’t suffice.
That's entirely your choice. This is the offering of a workaround while we are working on something better.
Two things:
- The ISP host names are correct host names. They are what the (user-)configured upstream DNS server told Pi-hole.
- The other feature branch we're talking about allowing multiple host names per device (one per IP address to be precise). This will not allow you to specify the one correct host name. However, it will allow you to see all host names. This should be helpful.
One example from my network table (I'm running the new branch):
With ‘correct’ hostname I meant using a local hostname instead of a global one. (If I’m correct about this...)
Will this new feature affect the queries page (and the dashboard and so on)? I.e. will OP be able to distinguish all the “broadband.bt.com” clients without having to look at a MAC address and looking up the hostname corresponding with that MAC yourself in the network table? (This can ofcourse already be done via the admin interface if you’re running Pihole DHCP.)
Thanks for clarifying some things.
How would you detect this reliably?
I have a website for my family and, for convenience use internet-radio.myfamilyname.nl as host names for devices. This record only exists in my local network and are build by my DHCP server which knows that my local domain is myfamilyname.nl
I run this branch myself. The host names are still be the host names associated to the addresses.
Again, I think before they can change their implementation, we need to find a way to distinguish bad (=unwanted) from good (=wanted) host names. This still doesn't seem clear how to do.
No idea, maybe the devs will figure this out some time in the future. I happen to know that public IPs have a public hostname assigned by an ISP (such as {public ip with dashes}.cable.dynamic.v4.ziggo.nl). IPv6 GUA is in fact public and thus there is a public(/global) hostname just like IPv4, e.g. 2001-1c00-0000-0000-0000-0000-0000-0000.cable.dynamic.v6.ziggo.nl. Because my router doesn't support ULA (fc00, fd00) to use for private IPs, I stick with GUA. The system designed for ULA is different compared to private IPv4. I don't think making use of ULA will solve anything related to hostnames. Maybe something related to DHCPv6 packet inspection or DUID will help? I'm afraid I can't add anything else to this, since my knowledge of IPv6 is limited.
I have to say, I wouldn't mind if my admin console shows both the unwanted and wanted hostnames on all pages where hostnames are shown (except for DHCP...).
Any idea @DanSchaper?
I would like to avoid the necessity of DHCPv6 anywhere in Pi-hole.
Rethink this statement after realizing that your devices with 60 IPv6 host names will have 60 (valid!) ISP host names and one valid IPv4 host name (likely the one you want to see).
Well then, your network table must be a PITA to scroll through considering you’re running that branch. 
I'm not the person you need to ping on this.
No, we are aware of this and show at most 3 host names and addresses (the three most recent ones) per line. Everything else gets hidden in a hover-tooltip to stay out of your way.
Ah, just like it shows a maximum of 3 IPs with a tooltip to view the rest. However, there’s always an IPv4 address first, followed by IPv6 addresses.
I have the feeling that it may be necessary to put some context here. I'm not a big fan of saying something is better or worse without any proofs (or at least links to such) for your point of view. It may be biased and others can follow you "better" when you give proofs (I will not give a proof for this "better" here, though).
Not only that IPv6 solves the shortage in IPv4 addresses (this is known to most), but it also solves some more technical things in the background. Some of them are (in no particular order).
- IPv6 provides better end-to-end connectivity as NATs are not needed
- IPv6 offers better autoconfiguration abilities
- IPv6 offers better (in terms of more fine-grained) QoS support (check "Flow Label field" if you are interested)
- IPv6 offers greatly improved multi- and anycast support. Especially considering traffic that is consumed by a lot of people at the same time (think of a live stream of some big event), this can severely reduce the strain on the backend infrastructure.
- IPv6 has a simplified header structure compared to IPv4. This leads to faster hardware routing.
The last point may actually be the most important bit! In direct comparison between Ipv4 and IPv6 traffic going once around the globe, you can typically see some 10% in reduction of latency. Of course, this can vary a lot, however, it will give you at least some feeling.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.