R7800 router firmware update causing Pi-Hole problems

#1

Please follow the below template, it will help us to help you!

Expected Behaviour:

[DNS queries should take a bit as they are done, but not on further use]

Actual Behaviour:

[DNS Queries are taking very long (multiple seconds, or even time outs, and have gotten errors along BAD CONFIG in the past)]

Debug Token:

[https://tricorder.pi-hole.net/6yvjpogwk7!
ace]

Have been having issues since updating to 4.2.2; no issues beforehand. DNS resolver was actually failing to work at all at first, then 30 minutes later started up but things have been glacial since (5 seconds to resolve). At one time I had 334,000 DNS injections for the default 10,000 slots. IPV6 is not used by ISP, just disabled in router (7800 that was just updated as well), been trying to find out how to do it in the pihole but having issues.

restarting systemd-resolver seems to help but process tends to continue to lag, though latest restart (the one from this debug token) seems to be ok.

Would appreciate help if I should disable ipv6 for now, or if something else is causing havoc.

0 Likes

#2

It doesn’t look like any clients are using Pi-hole for their queries. Can you run sudo tail -f /var/log/pihole.log and try using a client to browse or generate dns queries? You should see the activity in the tail session. If you are not seeing any activity then the Pi-hole is not being used.

0 Likes

#3

Yup, there’s a flurry of activity when I visit a site, and generate queries. In fact I noticed it states that it reaches the max concurrent dns queries quite a bit.

It seems to query the same sites over and over.
Mar 24 12:58:39 dnsmasq[547]: forwarded 242.91.30.64.in-addr.arpa to 208.67.222.222
Mar 24 12:58:39 dnsmasq[547]: query[PTR] 242.91.30.64.cpe.townisp.com from 192.168.1.1
Mar 24 12:58:39 dnsmasq[547]: forwarded 242.91.30.64.cpe.townisp.com to 208.67.222.222
Mar 24 12:58:39 dnsmasq[547]: query[PTR] 0.0.0.224.in-addr.arpa from 192.168.1.1

I’m unsure why its asking for unplaced ip’s to openDNS servers. (noticed it seems to be occuring from DYNDNS entries…)

I have made a new debug token after generating a ton of entries:

https://tricorder.pi-hole.net/5kro1ygufk!

0 Likes

#4

It’s forwarding requests to OpenDNS as that’s what you have configured it to do.

    PIHOLE_DNS_1=208.67.222.222
    PIHOLE_DNS_2=208.67.220.220

pihole-FTL / dnsmasq is restarting every 10 seconds or so, and nothing is actually being written to /var/log/pihole.log, have you disabled logging?

   Mar 24 03:43:20 dnsmasq[14569]: started, version pi-hole-2.80 cachesize 10000
   Mar 24 03:43:20 dnsmasq[14569]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
   Mar 24 03:43:20 dnsmasq[14569]: using nameserver 208.67.220.220#53
   Mar 24 03:43:20 dnsmasq[14569]: using nameserver 208.67.222.222#53
   Mar 24 03:43:20 dnsmasq[14569]: read /etc/hosts - 5 addresses
   Mar 24 03:43:20 dnsmasq[14569]: read /etc/pihole/local.list - 4 addresses
   Mar 24 03:43:20 dnsmasq[14569]: read /etc/pihole/black.list - 0 addresses
   Mar 24 03:43:30 dnsmasq[14700]: started, version pi-hole-2.80 cachesize 10000
   Mar 24 03:43:30 dnsmasq[14700]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
   Mar 24 03:43:30 dnsmasq[14700]: using nameserver 208.67.220.220#53
   Mar 24 03:43:30 dnsmasq[14700]: using nameserver 208.67.222.222#53
   Mar 24 03:43:30 dnsmasq[14700]: read /etc/hosts - 5 addresses
   Mar 24 03:43:30 dnsmasq[14700]: read /etc/pihole/local.list - 4 addresses
   Mar 24 03:43:30 dnsmasq[14700]: read /etc/pihole/black.list - 0 addresses
   Mar 24 03:43:42 dnsmasq[14869]: started, version pi-hole-2.80 cachesize 10000
   Mar 24 03:43:42 dnsmasq[14869]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
   Mar 24 03:43:42 dnsmasq[14869]: using nameserver 208.67.220.220#53
   Mar 24 03:43:42 dnsmasq[14869]: using nameserver 208.67.222.222#53
   Mar 24 03:43:42 dnsmasq[14869]: read /etc/hosts - 5 addresses
   Mar 24 03:43:42 dnsmasq[14869]: read /etc/pihole/local.list - 4 addresses
0 Likes

#5

And where are you seeing alerts that you have reached max concurrent threads?

0 Likes

#6

When I did sudo tail -f /var/log/pihole.log I would get the error once in a while. I’m trying to have it happen again but its not cooperating, of course.

I at one time did disable logging, and purged the log, and then enabled logging. The web settings state that logging is enabled. Is there something that could be causing this error? This is starting to feel more and more like a “re-install” situation the more I’m hearing. No idea why the dnsmasq is restarting every 10 seconds.

EDIT: I tried a repair, didn’t seem to help. Here’s what happens when a new domain is accessed or used: https://pastebin.com/d60i1Z7k Line 303 is the DNS connection line error mentioned prior.

0 Likes

#7

192.168.1.1 is misbehaving badly. It’s flooding your Pi-hole with requests and causing a miniature denial of service attack. What kind of device is at that address?

0 Likes

#8

Netgear 7800 – my router. Possibly a bug in its newest firmware then? I broke the cardinal rule of updating more than one thing at a time just before the issue began. New firmware is 1.0.2.62

I apologize for giving you guys work that may end up not being related to the pi :frowning:

I found a reddit thread: https://www.reddit.com/r/pihole/comments/al9qqv/netgear_router_no_longer_working_with_pihole/

0 Likes

#9

I was able to find a thread discussing this issue:

Seems like something in the firmware causes is to hate the pi and continuously ask for things from it, causing as you mentioned a DDOS of sorts…

I sincerely apologize for not finding this earlier! I’m usually quite good at checking forums and googling my way into solutions.

I downgraded to 1.0.2.60 and have immediately noticed the constant spam of PTR is gone from that one 242 address. I will report if there are further issues.

Thank you again for your time and for being good sports, and I apologize for the headache.

3 Likes

#10

Thanks for your post! Solved my problem as well. Hmm… maybe time to DD-WRT the 7800

0 Likes