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

[mercygroundabyss]

Anyone who's having issues with jailed AGH instances? Until openwrt updates the opkg version you can bypass and either install the beta or update to latest stable by removing the opkg version and using the manual install method.

AdGuardHome V107.6

Hello, Based on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268444 Came here because of log error: [fatal] initing hosts container: hosts container: path at index 0: stat etc/hosts: os: DirFS with empty root There is a known issue with adguardhome which has been rectified in later verison, current supported (https://openwrt.org/packages/pkgdata/adguardhome) version 107.6 has this flaw and I am unable to start AdGuard on my openwrt install: details: |Model|Linksys WRT3200ACM| |Archite…

[AlanDias17]

Update: I've opkg updated AGH from 0.107.6-1 » 0.107.18-1 and is working flawless on my RPi4. Well, I still get random packing udp packet: dns: buffer size too small error everytime I connect phone but that's it.

[andretoniolo]

Hi There,
Hope everyone is doing well!
Today, I've noticed I have a whole lot (>9 K only today!) of queries coming from my localhost (127.0.0.1) in my log.
All of them are PTR (xxxx.in-addr.arpa) queries.
I am pretty sure I messed up with some config, I just don't know exactly which one .
Any help is appreciated!

EDIT: I now suspect this started after I've installed the "bandwidthd" package. Every 2-3 mins I see a ton of those PRT requests in the log. This is the same refresh cycle as the "bandwidthd"...

[mercygroundabyss]

they should be resolved by openwrt (if that is doing your dhcp). Make sure the ptr setup is set to use dnsmasq. https://openwrt.org/docs/guide-user/services/dns/adguard-home#reverse_dns_rdns

If you have a different setup (eg if you using AGH on another device you need to add this to the upstream server list as follows.

[/168.192.in-addr.arpa/]192.168.1.10
or whatever your device is.

However I know depending on which version of AGH you have installed... they did patch a number of PTR issues. I know its been referenced in a earlier post in this thread. I know its fixed in 108. I'm not sure which version of 107 they patched it to.

Edit: found it. [How-To-Updated 2021] Installing AdGuardHome on OpenWrt [Manual and opkg method] - #231 by mercygroundabyss that post.

[andretoniolo]

Thanks a lot.
I will double check everything as per your suggestions.
I am running AGH on the the same Openwrt box i use as router, running the DHCP server for my LAN. It is a Nano PI 5.
As for the AGH version,I am running the Openwrt opkg version 0.107.18, which by the way I was having a documented issue that was preventing me to start the service. I temporally resolved that by making hosts = false in the AGH config file (https://github.com/AdguardTeam/AdGuardHome/issues/5264)

Thank you!

EDIT: PTR settings are as per the guide. I stopped bandwidthd and those queries from the localhost stopped. I am not really sure why they are not handled by Openwrt. Well, I do have a DNS forward set to the Openwrt IP on my dnsmasq though..

AGH DNS Settings:

One log entry of those thousands of PTR requests in the log:

[Llethur]

@mercygroundabyss

There are a few needed tweaks depending on if you selected listen on all interfaces during setup. To fix this some manual editing is required of the yaml file. By default AGH in its setup asks you what interfaces to bind to. It either lets you select a single interface or ALL interfaces. (That means if your WAN interface is up you will have DNS listening there. There is an issue in for that to be selectable so you can deselect WAN interfaces. Its currently filed as an improvement for the 108 version I believe)

Open the /opt/AdGuardhome.yaml file and find the following:

dns:
  bind_hosts:
  - 127.0.0.1
  - ::1
  - 192.168.1.1
  - fd1a:c860:7174::1
  port: 53

I never edited the adguardhome.yaml file during installation until I ran into trouble updating and installing packages via opkg line commands and the Luci interface. Opkg would time out on requests and give me error messages when trying to update. I did not think it was necessary to edit the adguardhome.yaml file, since I chose for Adguard to listen to the br-lan interface only during setup. After what seemed like ages of trying different solutions, I decided to edit the yaml configuration using WinSCP, as described in the example, and, to my surprise, opkg responded as intended. Just putting it up there for someone who comes across the same issue as I have. Solving the opkg issue now means that I can use Adguard home and install/update packages as appropriate. I'm posting this here if anyone else comes across the same issue.

[mercygroundabyss]

Sounds like your upstream DNS for your router not right. What you are describing is the router not having a separate DNS and instead is looping back through your AGH.

Make sure you don't have your upstream peer DNS ignored, or use my script to set a upstream DNS for your router using the routerDNS.sh script.

or do the following to re-enable using your ISP's DNS on your wan.

uci set network.wan.peerdns="1"
uci set network.wan6.peerdns="1"

[andretoniolo]

Hi, indeed they were both set to "0", i.e. ignoring advertised DNS server addresses from my ISP.
I switched both back to "1" as indicated. Anyway, that did not help as I continue to see tons of PRT requests coming from 127.0.0.1 every 2.5 mins due to "bandwidthd" trying to resolve hosts for my LAN.
All the rest works as expected, i.e. all the other individual hosts on my LAN show nicely in the logs.
This is what happens when I try to nslookup form the router's "diagnostics" tool within Luci:

Shouldn't those local lookups be going through 127.0.0.1:54 instead, as my dnsmasq is running on port 54?

Also, in my yaml config file, I had to set hosts: false as this is the only way to start ADG without a FATAL error.

[mercygroundabyss]

@andretoniolo

Shouldn't those local lookups be going through 127.0.0.1:54 instead, as my dnsmasq is running on port 54?

ensure your ptr lookups inside AGH are pointed at dnsmasq on port 54.
However I have had someone report they had to add their dnsmasq as an upstream to do lookups.

[/168.192.in-addr.arpa/]192.168.1.1:54

I suggest filling an issue on AGH bug tracker as to why ptrs are not being properly looked up.

@andretoniolo

Also, in my yaml config file, I had to set hosts: false as this is the only way to start ADG without a FATAL error.

That is a confirmed bug on 107 branch. See here

A way round this is to uninstall the opkg version and use my script to install the beta version, or remove the beta part to install the 107 updated branch direct from AGH team.

AdGuardHome V107.6

Hello, Based on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268444 Came here because of log error: [fatal] initing hosts container: hosts container: path at index 0: stat etc/hosts: os: DirFS with empty root There is a known issue with adguardhome which has been rectified in later verison, current supported (https://openwrt.org/packages/pkgdata/adguardhome) version 107.6 has this flaw and I am unable to start AdGuard on my openwrt install: details: |Model|Linksys WRT3200ACM| |Archite…

[andretoniolo]

Once again thanks a lot!
Just to confirm, yes PTR lookups are directed to dnsmasq port 54 in AGH:

Thanks!

[Llethur]

Thank you for trying to help, but my issue was solved as my previous post explained. I ran your routerDNS.sh script when I setup Adguard home on my router. Editing the Adguardhome.yaml file resolved the issue for me.

[mercygroundabyss]

@Llethur

I never edited the adguardhome.yaml file during installation until I ran into trouble updating and installing packages via opkg line commands and the Luci interface. Opkg would time out on requests and give me error messages when trying to update.

opkg not updating means your router DNS is looping via AGH. that is an incorrect configuration. Your router should be able to do DNS lookups on its own. An inability for it to do this will mean NTP updates will fail and your router clock will be incorrect and potentially cause other issues like SSL failures due to time sync issues. Either fix it so your ISP DNS is used or use the script to update your router to use an alternate DNS. The reason the router DNS is kept separate is due to the delay in AGH starting when the router boots. The router should have already booted, gained a connection and updated NTP time by time AGH starts.

Your AGH clients will still use your encrypted DNS provided by AGH.

[Cheddoleum]

(Slightly OT, sorry:) Per the AGH logs, Google Chrome (macos and android) is doing something a little odd. Whenever a domain is blocked (either by "default" behavior, resulting in 0.0.0.0, or NXDOMAIN behavior), Chrome immediately tries the same domain with my (local) search domain appended.

So if my search domain as handed out by DHCP were scorchedpotato.io, a blocked request from Chrome for evilhost.evil-tracker.com will be immediately followed by a request for evilhost.evil-tracker.com.scorchedpotato.io, which of course returns NXDOMAIN. Anyone else notice this behavior? No big deal but it does mean a wasted request to my router's local DNS for every request blocked by AGH and it'd be nice to know why Chrome is doing it and how to turn it off.

So far I haven't seen any other client do it apart from Chrome. Sorry to be a little off-topic, but it's something I've observed using AdGuard Home's logging and as a result of AdGuard Home blocking, and it's puzzling me. I assume Chrome thinks any request that returns 0.0.0.0 or NXDOMAIN might be for an undecorated hostname, so it tries appending the search domain just in case.

[mercygroundabyss]

This well-intentioned Chrome feature is causing serious problems

That is why.

[Cheddoleum]

I did find articles about that, but this seems somewhat orthogonal to that. The article describes Chrome initially attempting random lookups to see if ISPs are doing NXDOMAIN hijacking before deciding whether to enable its omnibox (search and url in the same address field) feature. What I'm talking about is appending the search domain to every failed lookup and trying again, every time.

Well, it does seem intuitive why they do it, if annoying. it's of course non standards-compliant and other browsers don't do it. It'd be nice to turn it off.

[mercygroundabyss]

I suspect you will only get an answer direct from google and they are unlikely to say other than "internal secrets".

As for standards and google? mmmh. "Don't be evil?" is slipping.

[Barney]

@Cheddoleum

So if my search domain as handed out by DHCP were scorchedpotato.io, a blocked request from Chrome for evilhost.evil-tracker.com will be immediately followed by a request for evilhost.evil-tracker.com.scorchedpotato.io, which of course returns NXDOMAIN. Anyone else notice this behavior?

Me too.

[OFZ]

Hi, sorry for my bad ENG, i want to uninstall this module. So i remove adguardhome opkg in luci. Now my router can't access internet (exclamation mark with wifi icon). Pls help

[AlanDias17]

You want to revert DNS server port in order to access internet. Go to Luci > DHCP and DNS > General Settings:

1. DNS forwarding to 192.168.1.1.
2. In Advanced, DNS server port to 53.
   Reboot router.

[OFZ]

Thank you very much