adguardhome

[neilo1]

Hello,

Is it possible to add adguard home in pi4 image? Is it better compared to the packages we are using in the built for adblocking and dns over https? https://forum.openwrt.org/t/how-to-updated-2021-installing-adguardhome-on-openwrt-manual-and-opkg-method/113904/400

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

Thank you,

[wulfy23]

i've dabbled with this package (implemented 90% of what is needed) in the past and issues have been touched on/discussed once or twice previously... that said, this was maybe a year ago and i'm sure there are likely some minor changes which might aid in it's use a little however i doubt any of them would have overcome the key issues adding it to this ( or any build which does not 'force' it for everyone )...

to re-iterate;

1. it's (dns) a fundamental service which needs to work out of the box
2. There are many ways of configuring a resolver and 'forcing' a certain one of them goes against the principles of this build
3. size was a considerable factor last time and while not a deal breaker this factor has alot of hosting / revision availability contraints
4. maintenance, if I support it, bundling internally is borderline mandatory and this means each build or bump i'd have to redownload/bundle/test etc. etc. (support is also in this category... so if someone were to setup their service to talk to another service... etc. etc. then that does not work on upgrade because of XYZ... I kinda just need to know how to make it work on upgrade for them... without effecting other users, at a code level in order to be able to include and maintain the inclusion of...

like other requests though, I would not totally disgard the possibility / probability and if say around three people wish to use this package/service, and at least one of them is an advanced user regularly willing to test and more importantly maintain the upper level logic (service configurables) of what is necissary to ensure it fires up reliably across diverse configuration environments... i'm sure some runtime/install conditionals can be implemented to make the service work semi-simply on this build...

see these questions re: what sort of stuff is needed for adding things https://github.com/wulfy23/rpi4/blob/master/misc/guides/i_need_something_added.md

for the above, and considering the broader need for such uses... i'd probably suggest a totally separate repo which is usable across any build for the runtime logic / user space components... (if not mainline) i'd be happy to contribute a little if it's beneficial if the above were to come about...

---

having said all that, i'm all ears about this service any comments... i.e. an advanced user might just change my above assessment with some key info...

i.e. 'there is a regularly updated opkg' which is simple to add to image builder...

or

'what about a totally separate build variant - without dnsmasq at all'

etc. etc.

always other ways of looking at things...

[neilo1]

I think without dnsmasq image will be better and when last time I tried, it was not auto starting after the reboot. And please make it possible to transfer config from this build to adguardhome build for a separate memory card.

There were issues with https-dns-proxy. I don't know if those are fixed or not but you helped me and since then my build has been running flawlessly.

[avhm]

I’d add a +1 on this, I’ve been trying it out in a docker container on a different machine and it’s really rather good.

I’ve previously been running Stubby instead of http-dns-proxy as a forward for dnsmasq & simple-adblock - which has also worked great, but the management UI and the configuration options (asynchronous race for multiple dns providers, quic support etc) in adguard-home are much nicer.

I’d be perfectly fine with a fork of the project, but that might add a good bit of maintenance overhead.

Perhaps an optional flag in the wrt.ini to trigger the setup script?

also, congrats on the news about your grandson, our first daughter was born this weekend, so have a similar feeling over here too :)

[wulfy23]

:) woohoo!

Previously (as may have mentioned above / before) I had written 'the back end' for putting it in the build... -setting it up -migration / persistence across upgrades

So basically you'd just set the wrt.ini flag and it would "take over" (mostly) would need to check but afair what I had done was forward AGH via dnsmasq and AGH was for clients only so router uses masq or isp dont remember which...

This allowed for the best 'resiliency' for router operations over upgrades and whatnot (early boot afair), at least that's what i'd thought at the time.

In the end I figured that 'I was making to many choices' for the end user/users and as soon as someone deviated from related configs their networking (dns) and related stuff (upgrades) would break

I will dig out the previous code I wrote this weekend... test it again and more clearly highlight topology / caveats etc. with how I had done it...

worst case scenario is that there is a "adguardhome flavour" and you'd be responsible for first setup? with ~maybe~ a new ini flag to disable DNSMASQ OR have it run on alternative ports or similar... (these tidbits are where practical input / consensus would be needed for it to work/well)

Other alternatives may be a build that has no dnsmasq at all OR making a custom AGH inItscript that is less persistent ( dynamically takes over in non-persistent manner with associated service validation - possibly at just the firewall/redirect level to simplify / minimise amount of config alterations? ) so that if there are issues router will fallback to dnsmasq etc. etc.

Lets see how we go...

(P.S. Last time was reading about this package ( 9+months ago) afair they were making inroads on it's dhcp service? for now i'll proceed assuming DNSMASQ is still network dhcp server, let me know if AGH DHCP is required / now robust / better / desired...)

---

edit: in order to test / activate when I can push, place the following in /root/wrt.ini (for now only the AGH_TOPOLOGY variable (and NET_DUMMY_NUM) is really used... but the rest gives you an idea of tunables / what the other settings are

NET_DUMMY_NUM=2

AGH_TOPOLOGY="internal" #tba alt topology "primarydns" etc.
AGH_FORCE_REDIRECT_CLIENTS=1
AGH_ADMIN_PASSWORD="adguardhomeowner"
AGH_ADMIN_PORT="3001"

#AGH_LISTEN_IPV6= #NOT USED YET PROBABLY NEED TO EXPERIMENT HERE
#AGH_CLIENT_LIST #NOT USED

(will probably need related "block DoT/DoH" variable/s also? well DoH is a list thing you'd have to do yourself in related block program but you get the jist)

[avhm]

Fantastic. Sounds like you’ve already got much of this in the works.

A flavour works for me - it is a significant size to bundle, and as long as that’s the main difference I’d hope it’s easy to maintain.

My 2c and how I have mine configured currently:

• I’d prefer masq to handle DHCP, with masq DNS set to an alternate port, and added as an upstream in AGH for .lan domain resolution / whatever local domains someone wants to add etc. I feel this is more flexible (and also allows AGH to populate hostnames with PTR requests).
• AGH ideally set as the published lan interface DNS - This is preferable to a forward from masq as it allows per client filtering / logging / management etc on the AGH side, otherwise it’ll just show all activity as the forwarder.
• I’m totally fine with WRT using masq / ISP as a fallback for DNS during setup.

I’ll make the config changes too. All makes sense.

edit: brevity! Edit edit: and thank you for continuing to support this build, I had a record uptime of 198 days on a recent build as I’d neglected my updates. Impressive.

[wulfy23]

Thankyou very much, that's exactly the kind of input needed to push this forward!

Especially when it comes to what's in the YAML and topology.

I've scraped together some initial code... quite sketchy but somewhere to start with from a build perspective.

agh

the "build" implementation of adguardhome is (for now); "agh"...

(just an alternative init.d script ~> YAML+dir+uci config file)

this means;

that it can persist/reside but NOT RUN? in parrallel with "normal" adguardhome package/binary installs for the most part at least that's the intention for now.

1. IPv4 ONLY
2. RELEASE (22.03) only
3. backup your dhcp,firewall,adguardhome and network configs just in case
4. if does not start at boot for time being you may need to manually start
5. VARIABLES / TOGGLABLES are not enabled yet but am interested what's needed
6. Basic stuff like client disabling DoH/T or ipv6 is assumed on your side
7. Currenltly used the 'opkg' adguardhome binary
8. Don't go too mad with AGH (yaml) settings, expect this to get zapped while we are testing
9. For now i've coded this in a way that should be supported on most devices (i.e. not build related per-se) to leave window open for contributors who may not be users of rpi-4

admin interface; http://172.16.231.1:3001 user:admin password:adguardhomeowner

to try:

curl -sSL https://github.com/wulfy23/rpi4/raw/master/utilities/agh > /etc/init.d/agh
/etc/init.d/agh enable
/etc/init.d/agh start

(if it says "listening issue" that's a false positive probably)

it should-ish support;

/etc/init.d/agh pause
/etc/init.d/agh resume

(i.e. management interface is still up but client traffic is not directed via agh e.g. for troubleshooting etc.)

NOTE: Its probably quite buggy so if it fails now try again maybe tommorrow evening or after a push or two

TODO: The following things are needed / and/or mandatory before I can push "agh" (but the actual "adguardhome" will be supported at least tryable in also in larger image when pushed...

aka

The plan is to support either ENABLED_SERVICES="agh" #<recommended OR ENABLED_SERVICES="adguardhome" etc. etc. (one or the other)

Where "agh" is 'the build' implementation and 'adguardhome' is pretty much user managed...

-Add ipv6 support -Refine / expand / fix firewall rules / logic including master/nft support -Test / resolve any firstboot concurrency / initialization quirks or requirements -YAML defaults / merge / migrations etc. -Alt Topology support or primary topology changes etc.

[avhm]

That was remarkably painless!

Setup & install was smooth, service came up correctly. FWIW, I did see listening issue logged.

This is a nice configuration (having the service on it's own interface) but is a little out of my comfort zone from a configuration standpoint, so please humour me if I've not understood something correctly.

After init, the LAN interface wasn’t publishing the adguard DNS by default - it may be because I already had a conflicting entry in my config dhcp lan during the script setup. It was previously list dhcp_option '6,192.168.1.129' - the docker host I was running the AGH container on. But, even after removing this, AGH still wasn't being used.

Swapping this entry post setup to list dhcp_option '6,172.16.231.1' is now working, but i'm unsure if this is the intended configuration.

Setting:

local_ptr_upstreams:
    - 192.168.1.1

Works great for internal hostname resolution too, perhaps this could be set in the default config (address for the active masq DNS replaced ofc) as I can't see a reason this would be undesirable.

I'll gradually let all the clients on my network move over to this service as they refresh their leases, but so far, looking really great.

Edit: and running really great too!

This is with a mixture of quic & tls resolvers

[wulfy23]

Thankyou very much for testing and the (on point) feedback...

Roger re: tip for YAML settings, thankyou!

Yeah, I pulled around 1.5ms average (ISP router perf seems great) over 12hrs with ~15-20% blocked :) so definitely something very tempting for most users to switch to.

On performance... hmmm what else;

Chews up to 1GB of ram ( I have 2GB model and did not impact anything else but anyone else with 2GB or less and running other RAM heavy stuff... )

So Topology...

Basically, i'm really hesitant to mess with user (network/dhcp) settings... so the thinking is;

-that we spawn the service on a "virtual nic/ip" this could also be loopback (if intercepted from gateway ip set on clients and redirected) mac-vlan, netns or whatever, concept is similar...

-as 'dhcp' option 6 for telling clients where to send queries to can take time / introduce support / testing issues or delay, 'use' of the server is via redirects (the firewall 'chooses' who goes to adguardhome ip. for some clients to go to normal / alternate dns, we can have a VARIABLE, but for now i'll probably put AGH_REDIRECT_METHOD="dhcp" for peeps who want to manage from dnsmasq. (this would basically disable the firewall redirect), let me mull over this for a bit and see what perspires. (edit: i seem to have been preferring /etc/config/agh over variables in case other non-build users decide to contribute... so above will likely end up in config)

based on what you said above, sounds like the redirect was buggy at the time/version you had issues...

basically;

iptables -S -t nat

will show you the redirect (or not)

to really manually force it on for now (until I iron out bug), these will (should) work;

touch /tmp/.agh.firewall
uci -q set firewall.ahg.enabled='1'
uci commit
/etc/custom/firewall.agh

(the end game/preference for all the above (firewall method) is that basically if for whatever reason the service does not come up, then the redirect is never inserted and networking is still functional for users... ) (hmmm... I guess may need another config option for that, 'failsafe' / 'failsecure' or whatever...)

anyways, TLDR once again, i'll add / work on your suggestions. thanks.

---

edit: My stats and stuff seem not so persistent (reboots, service stop / start)... but been messing around alot so i'm keeping an eye on this...

---

edit edit:

had a record uptime of 198 days on a recent build as I’d neglected my updates. Impressive

hahaha, while i'd love to take the credit for that, have to defer to the upstream guys, don't get to find that one out for myself with all the building so always glad to hear about uptime tho'... I think the longest I went was 2 months-ish... :( I do however have some good stats with hundreds of upgrades and same sdcard still going (just I think), never had to re-install... (well for over 15months-ish anyway) :)

[avhm]

Ace. The way you've architected this is far better, and way more flexible!

Decided to take a dig into why the firewall rules weren't being applied for me - I was on the prior 'current' build (not the one you just pushed) and was seeing the following after removing the 2>/dev/null's from /etc/custom/firewall.agh:

root@PiRouter /53# /etc/custom/firewall.agh
Redirecting client DNS
Create NAT rules
Warning: Extension DNAT revision 0 not supported, missing kernel module?
iptables v1.8.8 (nf_tables):  RULE_INSERT failed (No such file or directory): rule in chain PREROUTING
Warning: Extension DNAT revision 0 not supported, missing kernel module?
iptables v1.8.8 (nf_tables):  RULE_INSERT failed (No such file or directory): rule in chain PREROUTING

I did get past this by updating kmod-ipt-nat to the opkg version, which then did allow the prerouting rules to populate, but I was still seeing responses from dnsmask when running dig from my local machine.

At this point I realised I was probably behind on the build, so updated to the latest current.

With the latest version at line 16 in /etc/custom/firewall.agh - it seems that LAN_NETWORK isn't being set, and the command returns empty for me. If I manually set this to LAN_NETWORK="192.168.1.0/24" I can then continue, but it then still errored when calling nft add rule nat pre udp dport 53 ip saddr ${LAN_NETWORK} dnat 172.16.231.1:53

It seems that on my system the nat table & pre chain did not exist. Once I'd created them, the script ran through and I can see the chain in nft list table nat 🎉 and the rules seem to work!

edit: My stats and stuff seem not so persistent (reboots, service stop / start)... but been messing around alot so i'm keeping an eye on this...

I had some slightly weird behaviour with this too immediately after setup, but it seemed to eventually save and retain the settings. Not sure why or what changed I'm afraid.

Also, can confirm that the service doesn't bring itself up on boot at the moment for me either.

Ram wise, I'm running this on a 1gb CM4, and it's not been too greedy just yet: but I'll keep an eye on this as we go. You can see where I added the Adblock home service and it's gradual devouring of my free memory (before it was restarted anyway) :)

Impressive progress for a weekend. Thanks Wulfy!

edit:

I do however have some good stats with hundreds of upgrades and same sdcard still going (just I think), never had to re-install... (well for over 15months-ish anyway) :)

Awesome. 2.5 years on the same SD card for me! Never needed to re-install, and never needed to reboot for any reason other than something intentional. 👍

[wulfy23]

brilliant, great feedback and apologies for making you dig to get the basics sorted... (but you probs learn't a little so likely win-win ish?) :)

cool, majority of that is me getting sloppy and mixing and matching code. apologies.

the not existing nat/prerouting tables/whatever however is a great find. on my system I probably have (had) some firewall rule that instantiates underlying xyz... will sort it out and finally push something a bit cleaner when it manifests... (I have a DNAT rule for SSH into the router from single public ip so I think this is it) (edit: it just kicked in that you'd used nft, pioneer! :) I didn't get that working yet!)

importantly,

1. i'm really glad your happy / comfortable / willing to work with the REDIRECT method
2. IPv4 is enough for now

those were sticking points with moving forward so will incorporate ability to just select certain MAC addresses / VLSM ( ip's / ip ranges ) when inserting the firewall rule/s. (on that note: users with more than one LAN segment and/or not using br-lan current setup will bork, note to self allow user to specify internal LAN physical adapters as workaround)

[avhm]

you probs learn't a little so likely win-win ish?

My pleasure, and absolutely! This was the excuse I needed to actually spend a few hours learning how iptables and nftables work, so thank you.

---

cool, majority of that is me getting sloppy and mixing and matching code. apologies.

No worries, supporting all possible configurations here is no easy task, but imo (and in my significantly less experienced view) this topology feels like a good way to go about it.

---

it just kicked in that you'd used nft, pioneer! :) I didn't get that working yet!

Haha, thank you. Well I had to learn somehow!

---

i'm really glad your happy / comfortable / willing to work with the REDIRECT method

Definitely - keeping the routing decisions local makes far more sense rather than relying on a published and rarely renewed lease. Keeps the door open for much smarter configuration per client / vlan / whatever etc too.

---

IPv4 is enough for now

My ISP still isn't handing out IPv6 addresses, so this isn't an issue for me, but I can't speak for others.

---

on that note: users with more than one LAN segment and/or not using br-lan current setup will bork, note to self allow user to specify internal LAN physical adapters as workaround

This might be somewhat limited to me in regard to users of this build, I have WIFIREMOVE=1 in my wrt.ini (no wifi on this CM4) and so no need for br-lan. However, I forget if WIFIREMOVE also nerfs the br-lan interface or if I did that myself.

A note here - On my machine at least, ip route returns the interface device, not the interface name, so the LAN_NETWORK assignment using ip route failed even if I specified lan as the grep filter so might need an alternate method.

root@PiRouter /52# ip route
default via 149.22.245.129 dev eth1 proto static src 149.22.245.251
149.22.245.128/25 dev eth1 proto kernel scope link src 149.22.245.251
172.16.231.0/24 dev dummy1 proto kernel scope link src 172.16.231.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1

thanks again, have a great week!

[avhm]

I've been keeping an eye on memory utilisation, looks like cached gets reclaimed as soon as it hits ~512Mb usage... or maybe triggered when free drops below about 160Mb.

Either way, seems totally fine on a 1Gb CM4 without any other memory hungry processes running, and it's extremely fast.