Maybe be doing something wrong...
have been reading this (PIHOLE_PTR=).
FTL log says:
PIHOLE_PTR: internal PTR generation enabled (pi.hole)
/etc/pihole/pihole-FTL.conf contains (not sure this is used to resolve pi.hole):
REPLY_ADDR4=192.168.2.57
REPLY_ADDR6=2a02:xxxx:yyyy:zzzz:c8bc:87ab:254a:8e2a
result of nslookup pi.hole:
nslookup pi.hole
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
*** Can't find pi.hole: No answer
Additional info:interface=eth0 (/etc/dnsmasq.d/01-pihole.conf) in my environment, replaced this with, per dnsmasq man instructions:
listen-address=192.168.2.57
listen-address=2a02:xxxx:yyyy:zzzz:c8bc:87ab:254a:8e2a
listen-address=127.0.0.1
listen-address=::1
DL6ER
September 30, 2021, 9:26am
2
Pi-hole PTR is only responsible for PTR requests.nslookup pi.hole is an A request so should have nothing to do with this.
Did the behavior change with respect to FTL v5.9 ?
YES, fired up my previous SD (yesterday)
pi@raspberrypi:~ $ nslookup pi.hole
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: pi.hole
Address: 192.168.2.57
Name: pi.hole
Address: 2a02:xxxx:yyyy:zzzz:425e:7127:30d2:d939
pi@raspberrypi:~ $ pihole -v
Pi-hole version is v5.4 (Latest: v5.5)
AdminLTE version is v5.6 (Latest: v5.7)
FTL version is v5.9 (Latest: v5.10.1)
edit@ChurchOfNoise
edit2here
DL6ER
September 30, 2021, 4:11pm
4
Could you enable both DEBUG_QUERIES and DEBUG_NETWORKING in pihole-FTL.conf and send me the snippet from both pihole.log and pihole-FTL.log when doing the nslookup ?
For me after running dig pi.hole @127.0.0.1
pihole.log:
Sep 30 17:48:54 dnsmasq[451]: query[A] pi.hole from 127.0.0.1
Sep 30 17:48:54 dnsmasq[451]: Pi-hole hostname pi.hole is Pi-hole hostname
pihole-FTL.log:
[2021-09-30 17:48:54.012 451M] Interfaces: Called from src/dnsmasq/forward.c:1550
[2021-09-30 17:48:54.012 451M] Configuration overwrites IPv4 address: 192.168.0.3
[2021-09-30 17:48:54.012 451M] Interface eth0 is not the exact interface we are looking for (30,0 != 1,0)
[2021-09-30 17:48:54.012 451M] Replying to pi.hole with NODATA due to missing iface address
result of dig pi.hole @127.0.0.1:
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> pi.hole @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 972
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi.hole. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 30 17:48:54 BST 2021
;; MSG SIZE rcvd: 36
DL6ER
September 30, 2021, 5:51pm
6
Thanks, I see that we forgot to set
next_iface.haveIPv4 = true;
here:
// Copy overwrite addresses if configured via REPLY_ADDR4 and/or REPLY_ADDR6 settings
if(config.reply_addr.overwrite_v4)
{
memcpy(&next_iface.addr4, &config.reply_addr.v4, sizeof(config.reply_addr.v4));
if(config.debug & DEBUG_NETWORKING)
{
char buffer[ADDRSTRLEN+1] = { 0 };
inet_ntop(AF_INET, &next_iface.addr4, buffer, ADDRSTRLEN);
logg("Configuration overwrites IPv4 address: %s", buffer);
}
}
causing FTL to think it has not IPv4 address, serving a NODATA reply. Similarly for IPv6. This will be fixed by
committed 05:47PM - 30 Sep 21 UTC
Signed-off-by: DL6ER <dl6er@dl6er.de>
Please try
pihole checkout ftl release/v5.10.2
rockpi@rockpi-4b:~$ dig pi.hole @127.0.0.1
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> pi.hole @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49883
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi.hole. IN A
;; ANSWER SECTION:
pi.hole. 0 IN A 192.168.2.57
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 30 20:3
[2021-09-30 20:36:44.908 13661M] Configuration overwrites IPv4 address: 192.168.2.57
[2021-09-30 20:36:44.908 13661M] Skipping interface vetheffcd02 (87,0): We are looking for (1,0)
[2021-09-30 20:36:44.908 13661M] Skipping interface veth03d3ace (85,0): We are looking for (1,0)
[2021-09-30 20:36:44.908 13661M] Skipping interface br-ab1e4e2beae9 (25,0): We are looking for (1,0)
[2021-09-30 20:36:44.908 13661M] Skipping interface br-ab1e4e2beae9 (25,0): We are looking for (1,0)
[2021-09-30 20:36:44.908 13661M] Skipping interface docker0 (6,0): We are looking for (1,0)
[2021-09-30 20:36:44.909 13661M] Skipping interface docker0 (6,0): We are looking for (1,0)
[2021-09-30 20:36:44.909 13661M] Skipping interface wg0 (4,0): We are looking for (1,0)
[2021-09-30 20:36:44.909 13661M] Skipping interface eth0 (2,0): We are looking for (1,0)
[2021-09-30 20:36:44.909 13661M] Skipping interface lo: Address type is overwritten by REPLY_ADDR4
something really strange here:
When the debug flags are set, it works
when the debug flags are removed, it stops working
tried several times, result confirmed every time...
jpgpi250:
When the debug flags are set, it works
when the debug flags are removed, it stops working
Confirm.
Guess it is because the added line is within an if(config.debug & DEBUG_NETWORKING) condition.
if(config.debug & DEBUG_NETWORKING)
{
char buffer[ADDRSTRLEN+1] = { 0 };
inet_ntop(AF_INET, &next_iface.addr4, buffer, ADDRSTRLEN);
logg("Configuration overwrites IPv4 address: %s", buffer);
next_iface.haveIPv4 = true;
1 Like
pihole-FTL -vv
problem appears to be solved...
thanks DL6ER and yubiuser for your very quick response...
system
October 7, 2021, 7:10pm
11
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.