What's new

AdGuardHome [RELEASE] Asuswrt-Merlin-AdGuardHome-Installer (AMAGHI)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Sounds like the guide that may have been needed was the Step-by-Step amtm guide, in the link in my signature below. :)
 
Sorry for asking a noob question. I am just starting on router based adblocker (from pihole). I was thinking of diversion, and on their website they show "What's new in amtm 3.2.3 - NEW: Adds support for Asuswrt-Merlin-AdGuardHome-Installer by SomeWhereOverTheRainBow". Its bit confusing give the first thread. As I understand this is new feature to amtm, and nothing to do with actual diversion codebase, right?
As @SomeWhereOverTheRainBow said in his reply, I am the author of both amtm and Diversion. I coded Diversion long before amtm was born overnight. For simplicity, I added news and instructions to the diversion.ch website, rather than get it its own domain. Both scripts are hosted on that website.
amtm is built into the router firmware since the release of Asuswrt-Merlin 384.15.
 
I'm trying out adguardhome currently. It's pretty cool script. I've disabled Diverison currently to test it out.

If I use the built-in DoT settings within the router, do I need to also enable this as well under encryption settings inside AdguardHome website (192.168.1.1:12345/#encryption)?

Do I check the box that reads:
Enable encryption (HTTPS, DNS-over-HTTPS, and DNS-over-TLS)
 
I'm trying out adguardhome currently. It's pretty cool script. I've disabled Diverison currently to test it out.

If I use the built-in DoT settings within the router, do I need to also enable this as well under encryption settings inside AdguardHome website (192.168.1.1:12345/#encryption)?

Do I check the box that reads:
Enable encryption (HTTPS, DNS-over-HTTPS, and DNS-over-TLS)
Don't mess with the encryption page unless you are trying to host your own doh, DoT, or doQ server. To do such, you would need to run a ddns service and point adguardhome at the path of your letsencrypt cert and key. Also, you would need to run
netstat -nlp | grep 443
To confirm you have all the ports available and not used. Obviously you would do the same for 853 and the DoQ port.

Not to forget to mention, you would also need to open those same ports on your firewall.
 
Last edited:
I appreciate the response. I won't mess with none of that.

I did try these 2 commands to check adguard was running properly:

Code:
pidof AdGuardHome
/opt/etc/init.d/AdGuardHome check

The 1st command return a number = gtg.

However, the 2nd check return this:
Code:
admin@GT-AX11000-xxx0:/tmp/home/root# /opt/etc/init.d/AdGuardHome check
-sh: /opt/etc/init.d/AdGuardHome: not found

Everything seems to be running smoothly though.
 
I appreciate the response. I won't mess with none of that.

I did try these 2 commands to check adguard was running properly:

Code:
pidof AdGuardHome
/opt/etc/init.d/AdGuardHome check

The 1st command return a number = gtg.

However, the 2nd check return this:
Code:
admin@GT-AX11000-xxx0:/tmp/home/root# /opt/etc/init.d/AdGuardHome check
-sh: /opt/etc/init.d/AdGuardHome: not found

Everything seems to be running smoothly though.
If you want to change what dns servers you are using, in the first post I provided details of where to do that

Here is a list of servers


If you right click and copy the link provided by the webpage that says Add to AdGuard.
1641656346036.png


it will provide you with a sdns:// format that is easily portable to AdGuardHome upstream server section.


Example:
sdns://AgcAAAAAAAAAAAAPZG5zLmFkZ3VhcmQuY29tCi9kbnMtcXVlcnk


which is for AdGuards default DoH service.
 

Attachments

  • 1641655852065.png
    1641655852065.png
    203 KB · Views: 482
Last edited:
I appreciate the response. I won't mess with none of that.

I did try these 2 commands to check adguard was running properly:

Code:
pidof AdGuardHome
/opt/etc/init.d/AdGuardHome check

The 1st command return a number = gtg.

However, the 2nd check return this:
Code:
admin@GT-AX11000-xxx0:/tmp/home/root# /opt/etc/init.d/AdGuardHome check
-sh: /opt/etc/init.d/AdGuardHome: not found

Everything seems to be running smoothly though.
Refresh your page and take a look above, I updated it to be more detailed!
 
I appreciate the response. I won't mess with none of that.

I did try these 2 commands to check adguard was running properly:

Code:
pidof AdGuardHome
/opt/etc/init.d/AdGuardHome check

The 1st command return a number = gtg.

However, the 2nd check return this:
Code:
admin@GT-AX11000-xxx0:/tmp/home/root# /opt/etc/init.d/AdGuardHome check
-sh: /opt/etc/init.d/AdGuardHome: not found

Everything seems to be running smoothly though.
The second check was missing an S61

try running

Code:
/opt/etc/init.d/S61AdGuardHome check
 
The second check was missing an S61

try running

Code:
/opt/etc/init.d/S61AdGuardHome check
Appreciate the assistance.

I went back to use unbound and saw some tips on setting up unbound and adguard in some earlier post.

Does this look correct to setup in the Upstream DSN servers with unbound & adguard running together?

Code:
[/use-application-dns.net/]192.168.1.1:553
[/dns.resolver.arpa/]192.168.1.1:553
127.0.0.1:53535
tcp://127.0.0.1:53535

This is what I'm getting when I run netstat -nlp | grep '53'

Code:
admin@GT-AX11000-xxx0:/tmp/home/root# netstat -nlp | grep '53'
tcp        0      0 127.0.0.1:553           0.0.0.0:*               LISTEN      12523/dnsmasq
tcp        0      0 192.168.1.1:553         0.0.0.0:*               LISTEN      12523/dnsmasq
tcp        0      0 127.0.0.1:47753         0.0.0.0:*               LISTEN      3855/mcpd
tcp        0      0 0.0.0.0:3702            0.0.0.0:*               LISTEN      12539/wsdd2
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      12024/unbound
tcp        0      0 127.0.0.1:53535         0.0.0.0:*               LISTEN      12024/unbound
tcp        0      0 :::53                   :::*                    LISTEN      4486/AdGuardHome
udp        0      0 127.0.0.1:553           0.0.0.0:*                           12523/dnsmasq
udp        0      0 192.168.1.1:553         0.0.0.0:*                           12523/dnsmasq
udp        0      0 0.0.0.0:3702            0.0.0.0:*                           12539/wsdd2
udp        0      0 192.168.1.1:53923       0.0.0.0:*                           12286/miniupnpd
udp        0      0 192.168.1.1:5351        0.0.0.0:*                           12286/miniupnpd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           10948/avahi-daemon:
udp        0      0 127.0.0.1:53535         0.0.0.0:*                           12024/unbound
udp        0      0 :::53                   :::*                                4486/AdGuardHome
unix  2      [ ACC ]     STREAM     LISTENING       3553 1270/nt_actMail     /var/run/nt_actMail_socket


Everything seems to running smoothly, just let me know if the DNS upstream is gtg or if I need to make any changes. Sorry for the noob questions!
 
Last edited:
@SomeWhereOverTheRainBow One more issue I noticed. Before AdGuard, my local domain resolution was working with just hostnames. e.g. nslookup raspberrypi. But with AdGuarad it did not work.

Code:
$ nslookup
> raspberrypi
Server:         192.168.23.1
Address:        192.168.23.1#53

** server can't find raspberrypi: NXDOMAIN

I had to add my local domain in Upstream section (which you already add in Private reverse DNS servers section). So my current DNS setup is as below, which is providing valid local lookups.
1641686935594.png


Code:
$ nslookup
> raspberrypi
Server:         192.168.23.1
Address:        192.168.23.1#53

Name:   raspberrypi.local
Address: 192.168.23.15

Reading their documentations your implementation should have worked. Not sure if my network is any different since no one else have reported this issue.
 
@SomeWhereOverTheRainBow One more issue I noticed. Before AdGuard, my local domain resolution was working with just hostnames. e.g. nslookup raspberrypi. But with AdGuarad it did not work.

Code:
$ nslookup
> raspberrypi
Server:         192.168.23.1
Address:        192.168.23.1#53

** server can't find raspberrypi: NXDOMAIN

I had to add my local domain in Upstream section (which you already add in Private reverse DNS servers section). So my current DNS setup is as below, which is providing valid local lookups.
View attachment 38450

Code:
$ nslookup
> raspberrypi
Server:         192.168.23.1
Address:        192.168.23.1#53

Name:   raspberrypi.local
Address: 192.168.23.15

Reading their documentations your implementation should have worked. Not sure if my network is any different since no one else have reported this issue.
That depends on your setup. I was able to use the current arpa just fine. Not everyone has .local at the end of their raspberripi.
Mine is .mydomainname. If you want to resolve the issue, you need to set your routers domain to local, or modify your raspberrypi accordingly to your domain name.

1641689159263.png


At any rate you are using the wrong spot for defining a local request. It should be done in the Private reverse DNS servers. Using the upstream section has been known to break things at some point. AdGuardHome Devs only want you to use the upstream section if you are planning to send ALL your arpa. request to that. Otherwise you are leaking local client information to the upstream.

1641689564097.png
 
Last edited:
That depends on your setup. I was able to use the current arpa just fine. Not everyone has .local at the end of their raspberripi.
Mine is .mydomainname. If you want to resolve the issue, you need to set your routers domain to local, or modify your raspberrypi accordingly to your domain name.
I already have it since very beginning, I didn't change that for adbloker. This along with installer adding the - '[/$DOMAIN/]$(nvram get lan_ipaddr):553'" \ part should cover my case, right?
1641690496111.png


1641690512128.png


At any rate you are using the wrong spot for defining a local request. It should be done in the Private reverse DNS servers. Using the upstream section has been known to break things at some point. AdGuardHome Devs only want you to use the upstream section if you are planning to send ALL your arpa. request to that. Otherwise you are leaking local client information to the upstream.

I beg to differ here.. Per their code, if a domain is specified (e.g. [/local/]192.168.23.1:553) then all requests for that domain should only go to that upstream, dnsmasq in this example. So I am not leaking local client info to any other upstream. Also the "Private reverse DNS servers" is section is kind of misnamed. Its used for PTR requests, which is more of dig than nslookup, right? I cam across https://github.com/AdguardTeam/AdGuardHome/issues/3028#issuecomment-830246459 which seems to agree with my reading. Any way I added two entries in upstream, and all my tasmota client who were configured to talk to my pi are happy. btw // has the special meaning of “unqualified names only”, i.e. names without any dots in them, like myhost or router.

[/local/]192.168.23.1:553
[//]192.168.23.1:553
 
Last edited:
I already have it since very beginning, I didn't change that for adbloker. This along with installer adding the - '[/$DOMAIN/]$(nvram get lan_ipaddr):553'" \ part should cover my case, right?
View attachment 38453

View attachment 38454



I beg to differ here.. Per their code, if a domain is specified (e.g. [/local/]192.168.23.1:553) then all requests for that domain should only go to that upstream, dnsmasq in this example. So I am not leaking local client info to any other upstream. Also the "Private reverse DNS servers" is section is kind of misnamed. Its used for PTR requests, which is more of dig than nslookup, right? I cam across https://github.com/AdguardTeam/AdGuardHome/issues/3028#issuecomment-830246459 which seems to agree with my reading. Any way I added two entries in upstream, and all my tasmota client who were configured to talk to my pi are happy. btw // has the special meaning of “unqualified names only”, i.e. names without any dots in them, like myhost or router.

[/local/]192.168.23.1:553
[//]192.168.23.1:553
Maybe this was the case before v.0.106.0, but currently all private lookups must be handled by the private reverse DNS servers. otherwise defining private in the upstream means that local lookups may be sent to local or they maybe sent to upstream as well. while upstream look ups can be sent to local and upstream.

After thoroughly reviewing, the issue lies more in their documentation then anything. I will push a patch.

Now all private domain request will be handled in the upstream section.
 
Last edited:
Is it a good idea to fresh install adguard at every new update? Clear out any old setting? This seem to have work for me just incase come minor code change which need the old setting to clear out?
 
Clean install of 386.4, I ssh into the router and install EP and then AdBlock, but it just gets caught into a circle of installing. It clears the screen before I can grab the errors. Is there a place I can grab logs to show you guys?
 
Is it a good idea to fresh install adguard at every new update? Clear out any old setting? This seem to have work for me just incase come minor code change which need the old setting to clear out?
You can if you Iike to. The only differences are all the domain associations in the private dns section for moved from there to the upstream section while all the arpa. got left in the reverse dns section.
 
Clean install of 386.4, I ssh into the router and install EP and then AdBlock, but it just gets caught into a circle of installing. It clears the screen before I can grab the errors. Is there a place I can grab logs to show you guys?
Scroll up your ssh terminal and screen shot, that is the best log as everything can be seen there.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top