FTL Offline - Lost Connection to API

Expected Behaviour:

Pihole running and blocking ads

Actual Behaviour:

Pihole is not blocking ads, upon investigation to the web UI I see the message the FTL is offline and Lost Connection to API. This happens intermittently and appears to self heal every now and then but lately is more broken than working.

Debug Token:



[βœ“] Your debug token is: https://tricorder.pi-hole.net/pz9n5mt9hj



Welcome to the Pi-hole community, allantaylor8907. :slight_smile:

In addition to your pihole-FTL currently not being active, there are two major issues apparent from your debug log.

server=127.0.0.1

a) You've configured localhost (127.0.0.1) as one of Pi-hole's upstream DNS servers.
This may result in a DNS loop, as your Pi-hole would query itself infinitely when chosen.
In fact, I suspect this to have already happened, as your log shows an enormous 1.1 million DNS queries from just two clients during the last 24 hours.

*** [ DIAGNOSING ]: Networking
[βœ—] No IPv4 address(es) found on the br0 interface.
[βœ—] No IPv6 address(es) found on the br0 interface.
(...)
[βœ—] Gateway did not respond.

b) Your Pi-hole does not integrate properly into your network.

You could try to address both problems by running the following command from a terminal on your Pi-hole machine:

pihole -r

Choose reconfigure and pick valid upstream DNS servers when asked.

Hi! Thanks for the quick reply. The change to the upstream address being 127.0.0.1 was recent, as the docker file I am using specified that, I have reverted the change.

Regarding being unavailable on the network.
Pihole is running in a container and has its own IP exposed. I can access the UI and CLI to Pihole directly on its IP from any computer on the network. Can you clarify what may need to be done here?

new token after changing the DNS address :slight_smile:



[βœ“] Your debug token is: https://tricorder.pi-hole.net/0eh37a9x0t



I have tried reinstalling and reconfiguring with no success.
A few confusing points.
I am configuring based on: Docker Hub
Specifically:

Starting with the v4.1.1 release your Pi-hole container may encounter issues starting the DNS service unless ran with the following setting:

--dns=127.0.0.1 --dns=1.1.1.1 The second server can be any DNS IP of your choosing, but the first dns must be 127.0.0.1

But it was mentioned that localhost should not be one of the DNS servers so I am not sure what to do.

I am using bridged mode and giving pihole it own IP. I can reach the IP on the network and the router gives it out fine. I see requests hitting pihole for a few minutes before it completely falls over so I think the networking error is a false flag:

*** [ DIAGNOSING ]: Networking
[βœ—] No IPv4 address(es) found on the br0 interface.

[βœ—] No IPv6 address(es) found on the br0 interface.

[i] Default IPv4 gateway: 192.168.55.1
   * Pinging 192.168.55.1...
[βœ—] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)


[βœ“] Your debug token is: https://tricorder.pi-hole.net/5718lra6zk



Sorry for the misunderstanding.
Your original post didn't mention you are running a dockered Pi-hole.

You should not reconfigure a Pi-hole docker image, ever - it is intended ready for use.

That does not invalidate my earlier advice on not using 127.0.0.1 as Pi-hole's upstream DNS server, as this would create a DNS loop. Your current debug log shows you are still closing that loop.

Pi-hole's upstream DNS servers can be customised by setting Docker environment variables for Pi-hole, DNS1: <IP address 1> and DNS2: <IP address 2>.

Alternatively, you can change upstream DNS servers via Pi-hole's Settings | DNS pane as well.
Note those changes will only survive Docker container restarts if /etc/dndsmaq.d/ has been exported as volume (which it should be by default with the official image).

In contrast, the --dns Docker option you are referring to does configure DNS resolution for your Docker container, and should be set as described.

No worries! thats my fault for leaving out important information.

I think I closed the loop and was confused and overanalyzed after reading the readme.md for the container.

Can you confirm if I closed that loop please?



[βœ“] Your debug token is: https://tricorder.pi-hole.net/yupxgf6s0n



No, the contrary - but that's what you want, as you certainly don't want a DNS loop :wink:

You are now using the following four upstream DNS servers:

    PIHOLE_DNS_1=1.1.1.1
    PIHOLE_DNS_2=1.0.0.1
    PIHOLE_DNS_3=1.1.1.1#53
    PIHOLE_DNS_4=1.0.0.1#53

127.0.0.1 has vanished, so that's all good.
DNS 3 and 4 are redundant, as they are identical to 1 and 2, and could be
considered for removal.

Thanks

:sweat_smile: on closing the loop

Just wanted to circle back. I am seeing the same behavior with FTL Offline again.



[βœ“] Your debug token is: https://tricorder.pi-hole.net/ezzlcad9q4


Your Pi-hole assumes it is residing at

IPV4_ADDRESS=192.168.55.169

Yet there are no IP addresses bound to its network interface, and thus no connectivity:

*** [ DIAGNOSING ]: Networking
[βœ—] No IPv4 address(es) found on the br0 interface.
[βœ—] No IPv6 address(es) found on the br0 interface.
(...)
[i] Default IPv4 gateway: 192.168.55.1
[βœ—] Gateway did not respond.

It would seem that Pi-hole did not receive an IP address while starting.

Since an IP address wouldn't simply vanish:
Did you restart your Pi-hole Docker container and/or the Docker host OS ?

No...Its the strangest thing, I can see on the graph each time it drops out and comes back.
I have the pihole container statically assigned to that IP and running on an unraid server that stays on 24/7. I was just in the UI looking around and got the FTL offline message and lost connection to API and then 30 seconds later its back up and queries are streaming in, and then another minute or so later it falls back offline again.

Let me summarise where we stand:
We have confirmed that your Pi-hole runs if assigned an IP address, as with 192.168.55.169, after sucessfully avoiding a DNS loop in your configuration.

We also saw your Pi-hole losing network connectivity twice now, with no IP address assigned to your bridge interface.

Network connectivity is supplied by your UnRaid/Docker environment, Pi-hole just makes use of it.

You may have a better chance for support when frequenting their forums.

1 Like

are you running this Pi-hole for personal home use? That amount of queries looks quite large. To compare, my home network rarely breaks the 1000 threshold on my graphs.

Putting the intermittent service dropping / respawning together with the amount of queries I Think you're running out of shared memory and crashing FTL.

If you aren't expected this amount of traffic you may want to shut it down and secure your firewall / port forwarding.

Thanks for joining us, diginc.

Your observation suggests we should try to identify the probable origin of these large number of requests.

@allantaylor8907, let’s find out how large that number actually is.
Please run the following command on your Pi-hole machine:

echo ">stats" | nc localhost 4711 -w 1

And also check top allowed domains:

echo ">top-domains (12)" | nc localhost 4711 -w 1

as well as top blocked domains:

echo ">top-ads (12)" | nc localhost 4711 -w 1

Interesting observation, to clarify, this is personal use at home. and the only thing that is exposed over the internet is my plex server and maybe some camera devices, but to my knowledge they are dynamically handled and not static port forwarded.

Other potentially useful information:
Using Luma wifi - Pihole IP is network wide DNS address
I have 160gb of RAM on the server, so I can certainly allocate more I just wasn't sure how to do so up front - I am new to docker

root@46f87f65372f:/# echo ">stats" | nc localhost 4711 -w1
domains_being_blocked 1183930
dns_queries_today 1196356
ads_blocked_today 4149
ads_percentage_today 0.346803
unique_domains 1488
queries_forwarded 1189505
queries_cached 2702
clients_ever_seen 2
unique_clients 2
dns_queries_all_types 1196356
reply_NODATA 1
reply_NXDOMAIN 0
reply_CNAME 28
reply_IP 4
privacy_level 0
status enabled
---EOM---
root@46f87f65372f:/# echo ">top-domains (12)" | nc localhost 4711 -w 1
0 234516 debug.opendns.com
1 57446 _ldap._tcp.dc._msdcs.kershaw.k12.sc.us
2 47789 lb._dns-sd._udp.0.55.168.192.in-addr.arpa
3 44652 watchdog.lumaops.com
4 41987 cdn.samsungcloudsolution.com
5 30673 dnsmasq-monitor.luma.lumaops.com
6 29114 api-global.netflix.com
7 28453 macmanage-prod.us-east-1.elasticbeanstalk.com
8 27845 api-luma-prod.lumaops.com
9 27529 www-luma-prod.lumaops.com
10 27425 spectrum.s3.amazonaws.com
11 27411 api-luma-stage.lumaops.com
---EOM---
root@46f87f65372f:/# echo ">top-ads (12)" | nc localhost 4711 -w 1
0 1468 ichnaea.netflix.com
1 584 b.scorecardresearch.com
2 247 device-metrics-us.amazon.com
3 199 customerevents.netflix.com
4 164 udm.scorecardresearch.com
5 86 v10.events.data.microsoft.com
6 66 graph.instagram.com
7 61 telemetry.dropbox.com
8 55 aax-us-east.amazon-adsystem.com
9 55 beacons.gcp.gvt2.com
10 48 iadsdk.apple.com
11 45 app-measurement.com
---EOM---

edit: I enabled network wide firewall in Luma - continuing to monitor
edit2: I was in the dashboard and saw 5k plus queries stream in within a matter of seconds and then the FTL offline message. I am not expecting traffic like this as diginc mentioned - just a regular home use network. Any thoughts on tracking down the offender(s) ?

I Forgot to post similar issue about SHM flooding from github.

The signature we saw in this was /var/log/pihole-FTL.log showing lots of resizing of Resizing "/FTL-queries" in rapid succession often followed by crashes. Do you see that in your FTL log?

debug.opendns.com makes for a striking apperance here, with almost 250,000 queries.

Would you be able to pinpoint the device that is so desparate to send that many queries?

I do see resizing in the FTL log like you mentioned in rapid succession, but its crashing so fast I can't even get a screen grab.

It looks exactly like what was happening in the github link you mentioned, back to back increases until a restart occurs. I am going to investigate increasing the shared memory based on that article.

It seems that may only be a bandaid to a larger problem not directly pihole related. Because Pihole is not handling DHCP I cant get the address for the device making so many requests from there. Just curious if you had any ideas on that front. I thought wireshark but I think that only captures packets for the device its running on.

You wouldn't need Wireshark, as Pi-hole is only seeing DNS traffic, and it is perfectly logging DNS requests.

You should still consider finding the source for these requests, as it is their sheer amount that puts Pi-hole under stress.

Have a look at Tools | Tail pihole.log for details of requests being processed as they come in, or do a tail -f /var/log/pihole.log on your Pi-hole machine (<Ctrl>><C> will terminate).

Once you've identified that client, you'd have to find out why it is firing so many DNS requests.

1 Like

would top clients give away who the culprit is?

echo ">top-clients" | nc localhost 4711 -w1