Part of my reasoning for not going too complex is that AGH's DHCP is... rather simple and still awaiting some changes to bring it more inline with the far more powerful OpenWrt implementation.
Small changes and avoid breaking stuff. I deliberately aimed to avoid major changes to avoid breaking peoples installations. Break DNS and bad things happen.
Interesting experiment I had a look at. Since the 0.106.3 and 0.107.0 release the binary size (using ARMv7 as the sample) has grown a fair bit, in OpenWrt land this is more of an issue than other platforms for directly storing in flash/overlay which is what the opkg package will do. While there is exroot and persistent storage via USB etc which would be recommended, I did wonder if the binary can be compressed without breaking it.
Throwing the 0.107.0 ARMv7 release through upx, it compressed it down to 10 MB, down from 32.1 MB (original binary from GitHub) which is a 68% reduction. It runs on OpenWrt fine, there doesn't seem to any major issues, but I'm sure they'll likely be performance trade offs, possibly with startup time and maybe some calls within.
It did make me wonder though, if the binary continues to increase at such a rate without compression or optimisation during the build source phase, it's going to be very impractical for most routers to even have the opkg package install potentially.
I did raise a discussion on the AdGuard Home GitHub for comments.
I don't know if the build from source does any compression or optimises the release builds, I'm not really that experienced with Go related software. I'm going to run the compressed binary on my own router and see if there's any major issues though, 68% compression from the original is pretty good though.
Edit: The AdGuard team seem to think this is specific to 0.107.0: https://github.com/AdguardTeam/AdGuardHome/issues/4025
can i add my ipv6 to bind host?
You have already.
::1 is short form for your .1 address in ipv6 space.
127.0.0.1 is localhost.
::1 is ipv6 host
192.168.1.1 is ipv4 host.
I have a question, can i use AGH and ipset at the same time because when i redirect port 53 to agh it break my ipset rule ( example i use mwan3 ipset for some websites go through vpn, use AGH -> ipset not work or i use firewall to block some websites with ipset, it stop working when use AGH ). I can use vpn-policy-routing for it but i want use only mwan3. Tks.
try use the latest edge build they fixed some ipset errors in it.
What issue with ipset are you having? If you were previously using dnsmasq + ipset, you will need to migrate your ipset policies to AGH when used as the primary DNS resolver.
AGH has a different syntax for ipset policies. I wrote an example of how you create policies on the wiki, as it's not that clear from the official AdGuard Home wiki (or at least I didn't find it that clear).
I use mwan3 too and ipset is working fine based on my testing. I have several ipset routing rules in my mwan3 config which are working as expected, after migrating to AGH. I have confirmed the lookup of a domain in an ipset policy will get added to the referenced chain like dnsmasq.
Providing you have ipset policies configured in AGH, there should be no changes required in terms of mwan3, given AGH is not responsible for the policy based routing side.
I would setup a test ipset policy in AGH, confirm a lookup through AGH adds the IP address of the domain to the policy and then check your ipset rules in mwan3.
Not sure if this is the best place to provide wiki feedback, but regarding the Debugging section. It might be worth noting that the init script (at least of the opkg package) bridge AGH stdout/stderr to syslog, so you can query for errors via
# logread -e AdGuardHome
Noted and wiki updated. Thanks.
Looks like the AdGuard team have snuck in two stable releases since 0.107.0. There is now a 0.107.1 and 0.107.2. I've personally hit a bug that's fixed in the latest stable, I'll send a PR to update the opkg package to 0.107.2, seems to fix a few areas which some users might hit.
That's pretty much why i just use the edge builds. While stable builds are preferable, i do feel that AGH is definitely more agile/reactionary with builds.
As of yet i've not encountered any showstoppers with edge builds, but it does have its risks.
The development cycle currently seems very agile and rapid, but stable is always going to be preferred or a good idea, as eventually a stable release would need to be in master to then backport down to 21.02 or whatever the latest release branch is.
Maybe after the 1.0.0 milestone, releases may settle down a bit, but I'm happy to PR new stable releases, in conjunction with maintainers. It's easy enough to get alerts when new releases happen and I've got an OpenWrt buildroot setup to compile test packages.
I've tested doing the Nginx reverse proxy setup with AdGuard Home, it works, however at least on 19.07 there is a part in the default LuCI SSL Nginx config which can cause issues and had me banging my head against the wall for a while.
This can potentially break additional reverse proxy location rules based on the ordering, because many requests will match on this location rule first and hence never makes it to the desired proxy_pass call. I'm assuming it's there for caching purposes given it's targeting static resources, however this can break various CSS/JS and other asset requests for reverse proxied services, it did for AdGuard Home and Netdata (which I also happen to use)
Commenting it out, resolves the issue. It looks like in 21.02 the Nginx configs have changed somewhat so this might not be a problem for 21.02 and snapshot releases.
The reverse proxy method is probably the best recommendation in terms of following a standard procedure/setup guide, doing it this way means you don't have to configure TLS/HTTPS on AdGuard Home and instead utilise the SSL of LuCI. It also means you can have AdGuard Home on non standard ports or even the default TCP 3000 and simply proxy it to a more friendly URL.
Have added an uninstall script to my post. #justincase
Tided up the documentation a bit more. Also improved the layout.
Should be easier to read and also added bit more explanations.
@mercygroundabyss , I have a doubt: in the configuration of the reverse dns, you say to put 192.168.1.1:5353, but in the following figure it appears 127.0.0.1:5353. Which of the two is correct?
Both will work. The picture is an older one from when i was testing and i should have redone it.
127.0.0.1 is local loopback.
192.168.1.1 is the router IP.
(edit - I remember why I did localhost now. Stats tracking.)
Thank you for this excellent guide!
This was problematic for me:
#Set IPv6 Announced DNS
uci add_list dhcp.lan.dns='::1'
It instructed clients to set their ipv6 dns server as
::1 - which is equivalent to
127.0.0.1. Therefore, clients would to access a dns server on itself as opposed to the router.
Getting rid of this setting ensures correct behavior(on 21.02 atleast).
Note that you will need to add your router's ipv6 addr to adguard.yaml's bind_hosts too. You can find your lan ipv6 addr in network->interfaces on on the webui or
ip addr show br-lan on ssh.