Pi-Hole + Unbound with Nighthawk M1 hotspot. Was working, isn't now

Help Community Help
1

Expected Behaviour:

I set up a PiZero2 with PiHole and Unbound as per Craft Computing's YouTube video "You're running Pi-Hole wrong! Setting up your own Recursive DNS Server!"

The router I'm using it on is a Netgear Nighthawk M1 (aka MR1100 in some regions) mobile hotspot.

After some initial confusing behaviour which turned out to be due to me having put Google's DNS on my client machine (therefore bypassing the PiHole) I had it all working perfectly and tested on multiple devices.

Life was good.

Actual Behaviour:

Today I had need of the mobile hotspot so I powered it up, connected to it and couldn't get an internet connection.

I have made no changes to either the Netgear or the Pi configs. I literally turned it off and then a few days later back on again (and we all know that's supposed to fix things, not break them!)

I was able to log in to the PiHole interface on the LAN and to the Router's interface - but couldn't get out on the WAN.

The Netgear M1 interface is very limited and it forces you to have two DNS servers listed. I had set the first one to the Pi's IP address and the second one to 127.0.0.1 (I also tried it with 0.0.0.0)

With neither option working, I turned the DNS to 'auto' from the manual setting it had been on just to make sure that it wasn't an issue with the cellular data or coverage. On 'auto' DNS I was able to get connectivity (although obviously bypassing the PiHole)

The Tail pihole.log is showing me:

Feb  5 14:28:38 dnsmasq[611]: query[A] router3.teamviewer.com from 192.168.1.1
Feb  5 14:28:38 dnsmasq[611]: forwarded router3.teamviewer.com to 127.0.0.1
Feb  5 14:28:38 dnsmasq[611]: forwarded router3.teamviewer.com to 127.0.0.1
Feb  5 14:28:38 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:38 dnsmasq[611]: query[AAAA] router3.teamviewer.com from 192.168.1.1
Feb  5 14:28:38 dnsmasq[611]: forwarded router3.teamviewer.com to 127.0.0.1
Feb  5 14:28:38 dnsmasq[611]: forwarded router3.teamviewer.com to 127.0.0.1
Feb  5 14:28:38 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:40 dnsmasq[611]: query[AAAA] router5.teamviewer.com from 192.168.1.1
Feb  5 14:28:40 dnsmasq[611]: forwarded router5.teamviewer.com to 127.0.0.1
Feb  5 14:28:40 dnsmasq[611]: forwarded router5.teamviewer.com to 127.0.0.1
Feb  5 14:28:40 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:40 dnsmasq[611]: query[A] router5.teamviewer.com from 192.168.1.1
Feb  5 14:28:40 dnsmasq[611]: forwarded router5.teamviewer.com to 127.0.0.1
Feb  5 14:28:40 dnsmasq[611]: forwarded router5.teamviewer.com to 127.0.0.1
Feb  5 14:28:40 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:44 dnsmasq[611]: query[AAAA] init-p01st.push.apple.com from 192.168.1.1
Feb  5 14:28:44 dnsmasq[611]: forwarded init-p01st.push.apple.com to 127.0.0.1
Feb  5 14:28:44 dnsmasq[611]: query[A] init-p01st.push.apple.com from 192.168.1.1
Feb  5 14:28:44 dnsmasq[611]: forwarded init-p01st.push.apple.com to 127.0.0.1
Feb  5 14:28:44 dnsmasq[611]: forwarded init-p01st.push.apple.com to 127.0.0.1
Feb  5 14:28:44 dnsmasq[611]: forwarded init-p01st.push.apple.com to 127.0.0.1
Feb  5 14:28:44 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:44 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: query[A] 0.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: query[AAAA] 0.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: query[A] 0.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: query[AAAA] 0.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: forwarded 0.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: query[A] 1.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: query[AAAA] 1.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL
Feb  5 14:28:47 dnsmasq[611]: query[A] 1.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: query[AAAA] 1.debian.pool.ntp.org from 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: forwarded 1.debian.pool.ntp.org to 127.0.0.1
Feb  5 14:28:47 dnsmasq[611]: reply error is SERVFAIL

It goes on - but always with the SERVFAIL message and it doesn't seem to capture any requests coming in from client browsers.

I should add that I'm completely new to this. I set up another PiHole for my home network but I've never had to troubleshoot it because it's just worked. That's about my sum total knowledge of Pi and PiHole to date.

I'd be very grateful for any pointers you might have - or you might even know why it's a ridiculous idea to set up a MiFi hotspot with a PiHole (I don't, but then I don't know very much!)

It seemed to make a lot of sense to me to be blocking queries on something which uses a cellular plan. I might be deluded in my notion that it somehow reduces the amount of data usage by a significant amount but it's all part of experimenting and learning.

Anyway, I'm stuck and have tried everything I could think of so am hoping for some pointers

2

Really, this is a Pi-hole forum and you are asking a question about Unbound...

But, I see you posted "today", on the 8th, but your Pi-hole log thinks it is the 5th. That could be a problem.

3

This is posted in Community Help, and we offer a guide for unbound.

4

SERVFAIL with unbound is commonly related to inaccurate time on the Pi. The DNSSEC algorithm needs accurate time in order to complete the authentication.

Check the date/time on your Pi with the following command, and set it to your correct date/time as needed.

date

5

...and:

If this is a portable pi-hole that is not powered for days it will need to be fixed every time it is powered back on?

edit
And I will presume they travel; so the pi-hole will need local time?

6

Firstly, apologies if I posted in the wrong section or with the wrong request.

As a complete newbie I had no idea if the issue could be with PiHole, with Unbound, or even if the nature of a cellular connection might be causing some issues.

So the good news is that with your help and guidance I've pinpointed the issue which was the time/date.

To confirm some of the questions above: Yes, this is a portable PiHole which was unplugged for several days. Yes, this will travel and so the timezone will change as I do so.

The interesting thing is that I tried changing it in sudo raspi-config but it made no difference.

I tried again with sudo dpkg-reconfigure tzdata but I think that's just another way of getting in to the same place as raspi-config / localisation settings? It didn't work either.

Eventually I found reference to:
sudo date -s "12 FEB 2022 11:43:00"

This successfully changed the date, after which normal PiHole behaviour resumed (thanks again for helping me get there!)

The question remains why the NTP on the Pi didn't refresh itself but I suspect that's probably outside of the scope of this forum.

The Nighthawk M1 has a USB port which I use to power the Pi so my current working theory is that the Pi is booting faster than the M1 so the NTP on the Pi is trying to sync before the M1 has a connection ready for the Pi resulting in a failure to update the time.

I will test this theory tomorrow and if it doesn't break any community etiquette or rules I will post my findings in case it helps someone in future.

I've not found any details of anyone setting up a PiHole with a MiFi Hotspot - which I'm slightly surprised about so hopefully this will benefit others.

Again, I really appreciate everyone's input and help. I'm learning, slowly. Thank you!

7

Absolutely no need to.
You've posted a legit issue in the apropriate category (and even if you hadn't, switching categories is only a few clicks away).

It isn't directly related to Pi-hole (which suggests Community Help), but it's indeed DNS related (or DNSSEC, to be more precise).
As jfb has mentioned, DNSSEC needs a common time frame shared across involved parties. You would have run into the same issue if you'd turned on DNSSEC validation within Pi-hole.

Without the correct time, all public DNS requests will fail, including those for 0.debian.pool.ntp.org - which your RPi has issued in order to get the correct time information.

If your router supports acting as a time server, you could consider to configure your RPi to use your router's IP or its local name as a time server. The local name would require a Local DNS record or correctly configured Conditional Forwarding to work.

This wouldn't be feasible for a roaming device connecting to different networks with different routers, though.

RPis pretty much depend on time servers for accurate time, as they lack a battery-backuped RTC. Since those are quite inexpensive, you could consider to fit such an RTC to your portable Pi-hole RPi.

8

@ Bucking_Horn - thank you so much for the suggestion.

I didn't even know such a thing existed.

I'm lucky enough to live near a Pi store so I'm off there now in the hope that they might have some in stock.

Definitely looks like the best solution for my problem.

edit - they didn't have any so have ordered one online. Will update with results to hopefully give this topic a conclusion.

I also didn't answer the point about using the router as the time server - unfortunately Netgear have really restricted the options on the interface of the M1 (to the point where I was surprised they allowed a manual DNS option at all). I haven't found any option to allow this router to act as the time server.

9

I also use a travel Pi-hole connected to a router that I carry with me (somewhat similar to your setup).

As others have noted, the Pi does not contain an internal clock, and relies on external ntp servers to set the time. This leads to the problem where the Pi time is off, and it can't reach an ntp server to set the time. Endless loop.

Additionally, even if the Pi can reach an ntp server, if the time on the Pi is off by more than 1,000 seconds, it won't automatically sync the time.

Steps you will want to take:

  1. Set the nameserver on the Pi to something other than Pi-hole. Cloudflare, Google, Quad 9, whatever you like.

  2. Install an add-on RTC.

  3. If the two steps above don't work, here is what you can do when you set up the Pi at the remote site.

  • Using the configuration software (raspi-config or similar), set the timezone to your actual location.

  • If needed, manually set the time. Either of these commands will do it (you will need to change the parameters to the correct date/time):

    `sudo date --set="21 December 2018 11:53:30"`
`timedatectl set-time '2015-11-20 16:14:50'`

The RTC on my travel Pi has failed and I need to do these steps when I travel.

There is also an ntpd package that you can install. This allows you to override the 1,000 second error and force a time refresh.

The ntpd utility is an operating system daemon which sets and maintains the system time of day in synchronism with Internet standard time servers. It is a complete implementation of the Network Time Protocol (NTP) version 4, as defined by RFC-5905, but also retains compatibility with version 3, as defined by RFC-1305, and versions 1 and 2, as defined by RFC-1059 and RFC-1119, respectively.'

-g, --panicgate

Allow the first adjustment to be Big. This option may appear an unlimited number of times.

Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker configuration file directive for other options.

1 Like
10

wow - thanks jfb

I'll do some reading around the ntpd package / panicgate but that sounds like a great workaround.

If i've understood it correctly I should be able to set it for 31557600 seconds (aka 1 year) and as long as I connect the Pi to the internet once in that time period then it should sync the time?

So much more help than I was expecting. Thanks. Loving this community!

1 Like
11

Another option is to use any portable battery charger.

But unless you are staying in your time zone, whatever works to get it in sync will still need to be done

12

Note that putting on additional software is not the first option - get a RTC and install it. About $5 US on Amazon.

13

I already have one on order and am hopeful that it's all I'm going to need. Software option is a good backup and reading up on it is going to be good learning. A big part of why I dipped a toe into the world of Pi to start with.

I'm in Europe and the hotspot is going to be in a van so I'm unlikely to be jumping more than an hour with it.

Even if it does get upset, at least I know what I need to do to fix it now - thanks to you all.

15

There are videos on youtube on how to solder the GPIO pins cleanly on pi zeros.

Good luck.

16

For once, I'm ahead of that curve!

Bought some GPIO pins at the Pi Store and have watched a video on best practice on soldering them.

Not that my soldering skills are any good, but practice, practice, practice!

2 Likes
17

I just wanted to give this thread a conclusion.

After a bit of a struggle with my soldering skills and trying a few different options I found online about how to setup a 3231 RTC module, I eventually got the RTC working correctly.

The instructions which worked for me came from the embetronicx website. Not sure what the etiquette is on links on this forum but anyone who wants to find them should be able to.

In essence, I first enabled the i2c interface from the 'interfaces' option in an SSH session using
sudo raspi-config

Then I edited the /boot/config.txt to include the following:

dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds3231

Then rebooted the Pi and installed i2C-tools

sudo apt-get install i2c-tools

Then checked the device was identified using
sudo i2cdetect -y 1

Then I broke from the instructions slightly because I don't really know my way around Vi yet so I:

sudo nano/lib/udev/hwclock-set and commented out these three lines:

#if [ -e /run/systemd/system ] ; then
# exit 0
#fi

I also had the following line which was also commented out

/sbin/hwclock --rtc=$dev –systz

The instructions then went on to ask me to do stuff which I got stuck on but I'd already disabled the fakehw clock (and forgive me, I didn't make a note of where I found those instructions and can't remember the code I used, but it needed to be done in a few locations. I want to say three?)

Another reboot for good measure and then ran
sudo i2cdetect -y 1

I was encouraged by the fact that the RTC had swapped from showing as "68" to "UU" which suggested it was in use.

I've left the Pi powered off for 48h and just fired it up now and it's all working perfectly without me needing to SSH in and reset the time manually.

So thanks again to those who answered and helped a newbie fix a problem and learn a few things along the way. I hope, in time, to be in a position to repay that favour to someone else. In the meantime this thread has gone from fault to fix (even if in a bit of a clumsy way for a first time RTC install - for something so common it seems everyone has a different way of setting these up!) and hopefully might help someone else on their journey to building a portable Pi-Hole that gets powered off for extended periods.

1 Like
18

Blockquote "and hopefully might help someone else on their journey to building a portable Pi-Hole that gets powered off for extended periods.
.. . . . ... .... . . . .. . . :grin:
You just did.

19

Really pleased to hear it LilRedDog!

As a follow up - I left my portable Pi unplugged for about a week and the RTC module did it's thing and it just worked on power up again without needing any intervention.

Interestingly, I've now taken it abroad where there is a one hour time difference and it hasn't complained or needed any input from me. It's just working.

When I did a speedtest (which peaked at an impressive 170Mbps download - not bad for a SIM based hotspot!) it did show the country of origin of the SIM card, so I suspect that if I got a local SIM it would need the time adjusting - but it doesn't seem to need to with my 'home' SIM

Your milage may vary, but that's my experience with it so far. Currently blocking 26.6% of queries, so I just know it's saving me money on my roaming charges!

20

If you want to conserve even more traffic you can disable HTML5 Autoplay.

That is when you go to a site, like CNN, and they just start playing a video.

I do not know much about EU ISPs other than you all get much more for much less than we do in the US.
E.G. I get unlimited data, on my phone, but only 50GiB using it as a hotspot.
I have an iPhone, so I bought a lightning to HDMI adapter and watch movies on a monitor and my ISP thinks it is the phone.

Great to see you got it all working.

21

Interesting to see the differences LilRedDog.

I'm based in the UK and can get unlimited data for £15/month (about $20 USD) which I can use in a phone or a hotspot without distinction (the SIM will work in a phone just as well as a hotspot and it has unlimited calls and texts - it's not specifically sold as a hotspot SIM but it does specifically state that it can be used in a hotspot)

Ironically, I'm capped at 12GB of data per month when travelling in the EU but I can buy a bolt on for unlimited data daily for £5 GBP ($7 USD)

That still works out cheaper than any of the local monthly SIM cards I've found.

The frustrating part is I can't buy the bolt on from the hotspot. I have to transfer the SIM into my phone, buy the bolt on and then transfer the SIM back to the hotspot. That's annoying.

First world problems, I know. I still don't really understand why though!

The other thing I've noticed is that I'm getting speeds around 100Mbps even in the most rural areas. Best I've found was 170Mbps.

In the UK I'm typically getting 40Mbps from the same setup and the same SIM.

If I could get 100Mbps in the UK from my hotspot I wouldn't pay what I do for my fibre connection at home!

Autoplay isn't something I really encounter - I don't know if that's a regional thing or if it's the sites I typically visit.

I tried CNN just as an experiment and didn't have anything autoplay (I do always object to all cookies and anything which claims 'legitimate interest' - don't know if that makes a difference)