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

you have a different error this time.

On your install you got path not found.
This time you got my error (because AGH is already installed and setup).

In theory that means that AGH service is installed and ready to go.

But my suspicion is their recent changes are using systemd service install methods that OpenWrt doesnt support. Hence the path error. I will do some more digging and file a bug report.

3 Likes

Issue filed. Lets see what they say.

1 Like

@directnupe @StrikerFX They released a new edge build which will drop to using init.d rather than update-rc. Can you try again and see if its ok now?

EugeneOne1 commented 3 hours ago

mercyground we've just pushed the newest edge build. It now should be able to successfully install itself as a service on OpenWrt. Could you please check if it works?

2 Likes

Thank you so much for all you do. Mercygroundabyss you are simply the absolute best. I will get back to you just as soon as I get the latest Edge version installed and configured.
Once again I express my sincere gratitude for all you do to develop, educate and maintain AdGuardHome on OpenWRT.

Peace

2 Likes

Confirmed. Clean install on the new OpenWrt 22.03.0-rc4 on a NanoPi R4S router.

starting AdGuard Home installation script
2022/06/20 16:55:55 [info] service: control action: install
2022/06/20 16:55:57 [info] service: started
2022/06/20 16:55:57 [info] Almost ready!
AdGuard Home is successfully installed and will automatically start on boot.
There are a few more things that must be configured before you can use it.
Click on the link below and follow the Installation Wizard steps to finish setup.
AdGuard Home is now available at the following addresses:
3 Likes

Well apparently Cloudflare is having a bad day.

For those of you with DNS issues?

Add in the following as alternate upstreams

https://dns.quad9.net/dns-query 

https://dns-unfiltered.adguard.com/dns-query

Till cloudflare fixes their issues.

For those of you using cloudflare for your router dns.

9.9.9.9 is Quad9's ip4 address
8.8.8.8 is googles.

Add them as alternates till things get fixed.

3 Likes

Dear My Friend Mercy,
I was finally able to get AGH up, running with no issues. I changed to Quad9 for Bootstrap DNS. My main problem was that I was using too many and / or too aggressive DNS filters which would result in faulty connections.
Thanks for getting AGH fixed for all of us.

Peace

1 Like

Ok Folks. Bit of a tidyup.
Pinging a few people about my fixes. @jamesmacwhite @cah1982 @StrikerFX

Firstly the wiki : https://openwrt.org/docs/guide-user/services/dns/adguard-home

  • I've substantially re-edited the wiki to make it flow better.

  • A number of sections were moved and also edited so the Table of Contents now properly lists them as subsections.

  • Added an updated set of space requirements and example sizes.

  • Added in NFT tables replacement for IP Tables rule.

  • Added link to AGH page and their logo to the wiki.

  • Moved dnsmasq to port 54 to avoid clashing mDNS 5353 (new)

:warning:

  • I've highlighted NTP / SSL warning and made it highly prominent as this has bitten a few people. However looping your router DNS through AGH is NOT a recommended configuration for that very reason that NTP lookups WILL fail if the date/time is incorrect. There is also a race condition with the opkg version due to start up values that is still being resolved. Thus it is HIGHLY preferable your router uses a separate unencrypted upstream DNS to avoid the NTP issue.

Fixes for my thread :

  • NTP warning enhanced and link to wiki entry.

  • I've replaced my PTR picture in my thread to use 192.168.1.1 instead of local lookup. It was causing confusion and I've added a note to that too. Apparently I had fixed the wiki but not my thread. (Sorry @StrikerFX )

  • Added in NFT tables replacement for IP Tables rule and link to wiki.

  • Moved dnsmasq to port 54 to avoid clashing mDNS 5353 (new)

Additional:

Part of me wants to maybe duplicate the wiki and make one that shows the full path for a manual edge install as the thread install is somewhat difficult to read. You can use my thread with the wiki to do a manual install but you would have to keep checking where the process diverges.

Yet at the same time I am reluctant to duplicate it as large portions would be the same. I need to think about it and maybe ask the admins what their opinion is.

Any opinions from those who have followed my thread/instructions? Feedback is welcome.

(edit) or would a few extra sections marked optional on the main wiki with the manual thread method be better or more confusing?

(edit2) port 54 fix. (26/06/22)

4 Likes

Consolidate it.
The post is somewhat hard to follow, though I did get it installed.

Without this thread, I wouldn't have installed it.

1 Like

Hi Mercy,

Maybe one of the more experienced folks around here would like to chime in about redirecting OpenWrt builtin dnsmasq port to 5353, as this is also the port used for DNS-SD on Apple products and Avahi on Debian and Ubuntu.
I'll admit upfront that I'm not experienced enough to advise either for or against the use of this port, but I'm afraid it could interfere with locating services, specifically for things (e.g network printers, network scanners, you name it...) under the .local domain.

Also, by default, OpenWrt dhcp settings set the search domain to .lan, but I'm not sure what impact would result if users would manually change the search domain to .local, as I was once tempted to do, but ended up deciding to leave unchanged.

EDIT: In my own AGH edge setup I decided to use port 53000 instead for OpenWrt's builtin dnsmasq port.

1 Like

you can choose any port number you wish. Just check for it being reserved. I wasnt aware 5353 was used for DNS-SD and repeating port numbers is a common trick when "proxying" other ports. eg 8080 for http. I perhaps should have checked that. I could make a note in the thread and wiki you can use a different port as an option?

As a rule regarding ports, ports under 1024 are considered privileged ports and usually reserved.

if you change the search domain name you just have to change the redirect to match. All it does is change the appended domain.

1 Like

Having had a bit to ponder I think I may just redo my instructions and make it so dnsmasq is pushed from 53 to port 54.

54, Assigned, Xerox Network Systems (XNS) Clearinghouse (Name Server). Despite this port being assigned by IANA, the service is meant to work on SPP (ancestor of IPX/SPX), instead of TCP/IP.

While this is an assigned port, its likelihood of being used is low.

mDNS on 5353 is much more likely to be used and thus really should be avoided.

5353 Assigned Yes Multicast DNS (mDNS)

Port 8080 for the web interface for AGH is acceptable as Luci runs on port 80 and SSL on 443. Unless anyone has modified their OpenWrt install, 8080 should be free. If they have, then the nginx reverse proxy method will make the AGH interface available instead.

I will also make it clearer in my instructions that ports can be changed if required but point out there are assigned ports you should avoid as they are either assigned services or reserved and as a rule you should not use ports that are actively used for other services.

(edit) My thread and wiki now updated with port 54 instead and updated pictures for rDNS as well as info about reserved ports.

2 Likes

So my router lost power and time went back to 2013 the below is set up

[/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

but my router still cant sync time and have to do it through browser, rouoter shows the below

0.openwrt.pool.ntp.org

Am i missing somethin for adgaurd to let this pass when time is out of sync

i'd suspect its a timing issue.

Manually installed AGH comes up late in the boot process. OpenWrt will have the network and dnsmasq up and ready and fire a NTP update before AGH is active and thus will fail as AGH isn't active. The opkg version has a similar issue because the OpenWrt defaults try to load AGH before the network comes up. James was looking into if moving the startup time was a better idea.

What i suggest is to enable NTP logging with the following. Then manually adjust AGH startup with its init.d start values.

create a file /etc/hotplug.d/ntp/20-ntpd-logger and place the following in it.

#!/bin/sh
[ $ACTION = "step" ]    && logger -t ntpd Time set, stratum=$stratum interval=$poll_interval offset=$offset
[ $ACTION = "stratum" ] && logger -t ntpd Stratum change, stratum=$stratum interval=$poll_interval offset=$offset

This will make NTP updates show in the main log and then you can reboot the router and see if it updates or fails. Like this:

root@OpenWrt:~# logread | grep ntpd
Tue Jun 28 10:53:05 2022 user.notice ntpd: Stratum change, stratum=3 interval=4096 offset=-0.003520
Tue Jun 28 11:36:21 2022 user.notice ntpd: Stratum change, stratum=2 interval=4096 offset=0.002651

/etc/init.d/AdGuardHome

#!/bin/sh /etc/rc.common

USE_PROCD=1

START=95
STOP=01
<snipped>

Change the start value to make AGH load earlier in the boot process.

(edit) That all being said? Far safer to let the router do its own NTP via its own upstream and thus avoid the issue entirely.

Thanks so much for this write up! This is very detailed, but still very easy to follow at the same time.

I'm running into a problem (which I have seen further up, but the solution didn't seem very clear to me) whereby I'm unable to run opkg update or ping any sort of url for that matter following an Adguard Home install.

For example;

root@OpenWrt:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=250 time=3.424 ms
64 bytes from 1.1.1.1: seq=1 ttl=250 time=3.508 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.424/3.466/3.508 m
root@OpenWrt:~# ping cloudflare.com
PING cloudflare.com (2606:4700::6810:84e5): 56 data bytes
^C
--- cloudflare.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

This only appears to be at the router level, as I'm able to browse the internet fine on my devices connected to it (albeit with poor WiFi strength, but that's a whole other issue!).

I saw that there was a suggestion to update the upstream router DNS, but I've changed it from 192.168.1.1 in LuCI to 1.x.x.1 but that hasn't seemed to have fixed anything.

Any advice on this would be greatly appreciated!

check your ipv6 route/info. its trying to use ipv6 and not getting replys. you can disable ipv6 to ensure your ipv4 works ok and then trouble shoot your connection further. its usually the PD settings.

Do a separate troubleshooting post and detail your network there.

While I did use 5353 for this, I've always used 5335 when using unbound and pihole.
Nothing assigned to that port, no matter how unlikely.

On your system maybe.

However IANA specifies that port 5353 is allocated to mDNS and thus in order to ensure we do not cause problems by having a incompatible service on a port it should not be on, it is safer to use port 54 instead. You can also use other unallocated port like cesarvog did by using 53000.

The whole point of my instructions and also networking in general is to ensure we do not cause other issues with our changes. Standards are there for a reason :slight_smile:

Cheers, the router was fully booted, As i logged onto the web page, for either, but using the routers click here to load from NTP it wouldnt do anything, I had to load times from browser, then it worked

Do you mean dont have the router use the Adgaurd as its DNS and just manually set it to use 1.1.1.1 etc?

My point was not that 5353 was ok. I use 5335.
Seems like a better idea to use an unassigned port rather than an assigned port.
No matter how unlikely its use may be.

1 Like