The previous web interface displayed the IPv4 and IPv6 addresses for use for manual device DNS setups.
The web interface no longer provides the IPv4 and IPv6 addresses I need for manual device DNS setups.
This was removed, since the information is not always accurate.
https://github.com/pi-hole/AdminLTE/commit/cf917a6391a6a309be9dfdf87f0bde7c66d698b4
You can run ip addr to show this information, or generate a debug log with pihole -d and the information will be near the top.
I´m wondering if the removal was just a cosmetic change or something in the back also changed.
Because I´m running two IP addresses on one interface (eth0 as physical for service 1, virtual eth0:0 for pi-hole) and since updating to latest version Pi-Hole resolves "pi.hole" with IP from service 1 instead of the correct one (bound to eth0:0)).
Seems like the "IPV4_ADDRESS" from setupVars.conf is not respected any longer.
One update and such a mess... already spent one hour on this! No idea where to look at next.
See here:
Bugger me sideways. That´s it! I really should read the release notes twice before updating.
Set the right IP address with REPLY_ADDR4 in /etc/pihole/pihole-FTL.conf and now everything`s fine again. Still wondering if my setup is that special no one else ran into this issue. Anyway:
nslookup before (/var/log/pihole.log):
Sep 17 21:08:40 dnsmasq[27292]: query[A] pi.hole from 192.168.0.10
Sep 17 21:08:40 dnsmasq[27292]: internal pi.hole is 192.168.0.115 --> WRONG!
Sep 17 21:08:40 dnsmasq[27292]: query[AAAA] pi.hole from 192.168.0.10
Sep 17 21:08:40 dnsmasq[27292]: internal pi.hole is ::
nslookup afterwards (/var/log/pihole.log):
Sep 17 21:11:26 dnsmasq[2576]: query[A] pi.hole from 192.168.0.10
Sep 17 21:11:26 dnsmasq[2576]: internal pi.hole is 192.168.0.109 --> RIGHT!
Sep 17 21:11:26 dnsmasq[2576]: query[AAAA] pi.hole from 192.168.0.10
Sep 17 21:11:26 dnsmasq[2576]: internal pi.hole is ::
Thanks a lot @yubiuser, hero of the day!
We're going to look into your issue, especially
Virtual interfaces are somewhat seldomly used, however, I figured FTL would be able to handle them as the kernel documentation suggests that virtual interfaces are internally handled as separate interfaces (not the same interface with two addresses). Maybe this wasn't accurate (in which case the reported behavior is likely to be expected).
I'll configure a virtual interface on my Pi-hole at home myself and will report back.
edit Ah, yes. I see that it depends on how the virtual interface is created. If you just attach an IP address with a label like eth0:0, it will effectively be handled as the same interface by the kernel. FTL cannot differentiate the alias interface from the physical interface in this case.
Okay, I know what is happening: It is a bug in the interface routines of dnsmasq (which we are using here). Instead of storing the label (e.g., eth0:0), it stores only the name (eth0) which makes it impossible to differentiate between virtual and real interfaces later on in the application. I'll send a patch upstream to get this changed.
I found a way to circumvented the ambiguity in FTL and fixed another small glitch that we replied to queries with non-existing types (e.g. AAAA on an IPv4-only virtual interface) with :: instead of NODATA. Would you mind testing my changes?
Simply run
pihole checkout ftl tweak/pihole_virtual_interfaces
and test again if everything works as expected without the REPLY_ADDR4 setting.
Connected pull request:
https://github.com/pi-hole/FTL/pull/1170
@bcutter Can you help us ensuring that this bugfix fixes the issue you are seeing?
Hi, sorry for late reply.
I ran the pihole checkout command and testet DNS after that.
On Windows client now with nslookup pi.hole I get:
*** no internal type for both IPv4 and IPv6 Addresses (A+AAAA) entries for pi.hole available.
I have no idea what to do with this. In the end, it is NOT working (pi.hole can not be resolved at all while before it was at least redirected to the wrong IP address).
/var/log/pihole.log:
Sep 30 20:25:50 dnsmasq[8537]: query[A] pi.hole from 192.168.0.56
Sep 30 20:25:50 dnsmasq[8537]: internal pi.hole is internal
Sep 30 20:25:50 dnsmasq[8537]: query[AAAA] pi.hole from 192.168.0.56
Sep 30 20:25:50 dnsmasq[8537]: internal pi.hole is internal
I don´t use IPv6 by the way.
Furthermore I discovered using pihole status:
[✗] Pi-hole blocking is disabled
Unfortunately pihole restartdns could not fix this. Now my Pi-Hole seems to be broken!
Questions:
)? @DL6ERI´m going to update Pi-Hole now anyway and will probably need to re-add the REPLY_ADDR4 again because it seems like this "fix" has already been shipped with latest release according to Pi-hole FTL v5.10.1, Web v5.7 and Core v5.5 released – Pi-hole, hasn´t it?
Fix virtual interface address determination
This ensures appropriate addresses will be chosen for replies received on virtual interfaces.
pihole checkout master
Yes. There are currently global issues with SSL all over the place currently because a certificate used worldwide just expired some 15 minutes ago. You'll likely hear about it in the news tomorrow... That just as a warning if something goes wrong.
Ahm, that´s strange. Updated to latest version (branch change to master did this automatically).
Now even with REPLY_ADDR4 set in /etc/pihole/pihole-FTL.conf the problem still persists.
Again: testing/updating made it even worse (well basically same outcome: pi.hole can not be resolved, but this time I can´t fix it). What to do now? Processes already are interrupted on my network due to this... 
Generate a debug log, upload it when prompted and post the token here.
There is currently an issue with that, that is already addressed and might be resolved still tonight
https://discourse.pi-hole.net/t/pi-hole-ftl-v5-10-1-web-v5-7-and-core-v5-5-released/50009/12?u=yubiuser
OK, interesting. With checkout ftl release/v5.10.2 I ended up in the same situation as initially described in https://discourse.pi-hole.net/t/finding-pi-hole-ip-addresses-after-v5-4-update/49712/13: [✗] Pi-hole blocking is disabled
Now even with switching back to master branch I still get [✗] Pi-hole blocking is disabled - Pi-Hole won´t work at all.
/var/log/pihole_debug.log?Quick check: contains few sensitive information... ADMIN_EMAIL config, whitelist/blacklist comments, internal hostnames etc. ...
Anyway, I need to fix this quickly so tell me what to do please.
Yes.
No.
Yes - the uploaded file auto-deletes in 48 hours and is only accessible by a handful of people on the Pi-hole team.
Please try again. Some binaries were not uploaded due to the mentioned Let's Encrypt issue. and you received old versions not including the fix. We replaces all certificates by ones from another issuer for the moment and this should have fixed it.
Ran checkout ftl release/v5.10.2 again. Still Pi-Hole not working anymore. Therefore:
Not perfect but I´ll eat that for now because of time. Here we go: https://tricorder.pi-hole.net/MdH6Gqwu/