[How-To-Updated 2021] Installing AdGuardHome on OpenWrt [Manual and opkg method]

Its a little of both. If you had rebooted again after getting the new modem it would have picked up an NTP update and thus fixed itself. What happened is with your modem out, and you rebooting the R4S, it lost its time (because it doesnt have a RTC). Without a proper time sync, you cannot do encrypted dns lookups as it requires proper time/date to be set. Once you updated the time, it all fell back in place and carried on. This is why we either use unencrpyted DNS for NTP updates or put a NTP bypass in place.

Regarding the battery for the R4S, I investigated that and if you look on the R4S thread and on the wiki, i have posted pictures showing a rtc battery vs the case of the r4s. It would not be an easy fit. Potentially you could drill a hole in the external case and just tape the battery to the side or maybe use a smaller battery.

You are using the opkg version which writes those filters to the /tmp folder and thus looses them on reboot. The wiki has details on this https://openwrt.org/docs/guide-user/services/dns/adguard-home#installation

The default configured working directory will mean query logs and statistics will be lost on a reboot. To avoid this you should configure a persistent storage path such as /opt or /mnt with external storage and update the working directory accordingly.

Either switch to using the edge or stable version which will install to /opt or change the working directory for your existing install which can be configured in /etc/config/adguardhome. Be aware you do require about 100mb of space if you are making AGH persist in /opt.

However I suspect an easier fix would be to change the init script to run a bit later as the default values currently being used may be bringing AGH up before your internet is ready so the filters fail to update automatically on reboot. This would still keep your filters/data on /tmp but add a delay to AGH starting so the internet is up when it starts and updates filters.

@jamesmacwhite Is the opkg version using differing start / stop times still? I recall there was bit of discussion on it from last time this popped up?

1 Like

added

[/pool.ntp.org/]1.1.1.1
[/pool.ntp.org/]1.0.0.1
[/pool.ntp.org/]2606:4700:4700::1111
[/pool.ntp.org/]2606:4700:4700::1001

to the uptreams, openwrt has set to the below

image

How would i tell that its not encrypting it?

If you followed my instructions, your router is either using your ISP's DNS or you used my script to set it to cloudflare (or whatever provider you chose), then your router will be using unencrypted standard DNS. This avoids the issue of NTP updates being a problem as the time can now be set properly after it boots as usual.

AGH will use encrypted DNS for your LAN devices. The reason it wasn't working was because its time was wrong and thus would not get a https session to do DNS Lookups due to the invalid time/date. Once you updated the time it would have kicked back in and continued working.

Adding those entries wont hurt anything. It will just make it explicit to let those pass as unencrypted.

(edit - you can use sniffer tools to dump dns packets if you really want to get technical and check to make sure but it is rather bit of a technical skill to do)

Router /Adgaurd are on same NanoPi R4s, then fllowed your instructions and set this, if this is part you mean

That bit is for the PTR or Reverse DNS lookups. It tells AGH to pass any <host>.lan and <host> to goto dnsmasq instead.

Because we use OpenWrt to do dhcp we need to let AGH know to use dnsmasq (which we moved to port 5353) to look up internal DNS addresses. It should just be handled by the Reverse DNS part lower down but there was some "wierdness" in earlier builds. They have since updated PTR code as others were seeing PTR requests go upstream instead of being left to dnsmasq.

Isnt the top line to do with the encrypted cloudfare?

the green mark was just to serparete what you used and bellow what i added

yes. the topline is the encrypted cloudflare upstream

[lan]
[//]

are the ptr lookups

(edit - technically you only really require these if you are running multiple networks. its a catch all to force internal requests to go to to dnsmasq as per my previous post)

and then your ntp bypasses are the bottom.

I use 127.0.0.1 for local PTR requests because it shows up in the stats for easier tracking.
You can also use the local ip of the router (eg 192.168.1.1)

(edit 2 - And all of this can be avoided if you disable OpenWrt's DHCP and use AGH's DHCP because it will do it internally. However unless you have a fairly simple network I would take care before you try that route. AGH team still have yet to fix some DHCPv4/v6 issues and I am unable to test that yet. You are welcome to try but over there... there may be dragons! :boom: )
Its detailed in this post.

Cheers

Yeah I wouldnt want to switch any DHCP to AG, I do have allot of reserved addresses and MAC bindings for WOL.

As long as it can get the NTP after reboots/modem ever fails again, it should be fine.

Just left me head scratching for a hour, as to where issue was

It might be worth in your set up instuctions to possibly add them lines if its a router etc with no rtc battery etc

This bit is in my first post :slight_smile: but it is a giant wall of text. The opkg version is detailed on the wiki and thus is easier to read.

I have pondered if i should do the same maybe. That being said, a fair amount between the two versions is identical due to essentially the same process but different packaging.

Technically my "manual" process isn't "official" OpenWrt as its not packaged. The wiki is more for OpenWrt stuff directly. My scripting does however enable easier integration of AGH by making it more "new to linux" friendly. AGH's wiki expects you to understand what you are doing and thus the consequences of what you do.

yeah that might be what triggered me to think about the time settings once i saw the logs, as i remembered reading something about a time/date issue

But at time of setting it up, its all fairly new to me so thought it would be included in setup

I have it installed in /opt with all logs and filters in RAM, but when rebooting it automatically redownloads the filters...

edit: Sorry, I did not read "opkg"... mine is edge version.

/opt should be part of your filesystem and thus saved when you reboot. the opkg version saves to /tmp and is only in RAM so will be lost on reboot. That will make it reload filters on boot. If your setup has them saved to disk then it will reuse those instead. If you have edited the working config to have it write to ram then yes when you reboot those will be lost.

Any ideas why from one access point on network I see the below, its repeated every 3-5seconds

thats a reverse dns lookup. if you configured AGH properly it should pass that to dnsmasq to resolve.

I have 3 access points. And router. But just 1 access point it doing that

Strange thing is at 00.15 last night it stopped

In AG I never entered any AP details, just routers.

Not done it all today, so no idea why it did it yesterday, as there was thousands in log

1 Like

Thank you very much for reply. It was my mistake that didnt read it carefully. Now i install edge version and all working fine.

One last question, what should i include in System -> Backup and flash firmwares -> Configuration so i will have back up of all settings for future?
i put this patch /opt/AdGuardHome/AdGuardHome.yaml
Do i need also /opt/AdGuardHome/AdGuardHome.sig or anything else?

Thank you in advance

technically you could just backup the entire /opt/AdGuardHome folder and subfolders and redeploy it back to a new router. As long as you also re-run the script to move dnsmasq etc.

Personally i'd just reuse the script to reinstall from clean OpenWrt install and then port any yaml settings from your backup.

My reasoning for this is basically it doesn't take long to re-setup from scratch and AGH is evolving fairly rapidly. They have stated that config changes will come when they refactor certain modules (eg the DHCP settings etc)

It is far better to start with a clean install and debug or copy your tweaks to it, than to copy what was working but may be out of date from an old backup. (I've been bitten by this with yaml version changes in the past)

The yaml file and maybe the stats database are the only really "key" files in terms of data. Filters and the program itself can be redownloaded. Its your config setup that will be personal to you and also any statistics/querylogs you wish to keep. Everything else is replaceable really.

@mercygroundabyss, that part in your tutorial still goes 192.168.1.1:5353, but in the rest of the tutorial you say 127.0.0.1:5353, the part that contains 192.168.1.1:5353 is wrong? I always get confused on this part, sometimes I don't know if the correct thing is to add 127.0.0.1:5353 or 192.168.1.1:5353.

@mercygroundabyss Yes, it is possible the opkg version to not start on boot due to race conditions which certain network setups. Short of changing the start value, there isn't an easy fix because it is quite variable.

The consideration is AdGuardHome devs have made the start value equal to when /etc/rc.local is called, that's right at the end the boot process, which isn't ideal.

The issue is these network race conditions aren't always going to happen, it's down to individual setups. I'm wondering if the opkg version should allow you to configure a custom START value in it's config, as currently it will get wiped on any sysupgrade.

I'm not sure the solution is to just increase the START value to 95, as it's way too late in the boot process for something as critical as DNS.

The workaround I found is implementing a custom init script that runs before AdGuardHome to make sure other network conditions are available before it tries to start.

We could bump the start value a bit, as perhaps 21 is a little too early for all network related areas to be completed, but I wouldn't go as far as increasing to 95.

However one consideration is changing the bind_host/bind_hosts value from 0.0.0.0 could lead to this issue, if you set a specific address that's not available.

There is possibly an argument to leave the bind values as default to any available address, because the firewall rules should prevent access outside of the LAN. Likewise dnsmasq also defaults to all network addresses by default to bind to.

1 Like