while it's stand alone UI is cool and the manual method is not a huge hassle... automating the setup and bridging /etc/config/* to yaml via custom init.d(+installer||sysupgrade) in an updated opkg compatible package would surely be of more benefit to the community...
(much like what @erdoukki has done with the crowdsec package)
you can even support /tmp and /rwfs install methods via config option...
AGH team is aware of some of the issues and they want to redo some work as part of the 108 release.
Maybe that work will enable a better release for OpenWrt.
Their beta panel is somewhat... broken for one.
I think it has potential and definatly requires some further tweaking. Being able to go back to inital settings without having to edit the yaml file would be good. When i have some more time i'd like to revisit my original install notes and this thread to re-write up a more current version and advice for people using AGH. This thread is rather long and 2yrs old now.
107 works ok for me and the upgrades work seemlessly (as long as u keep an eye on diskspace otherwise they fail silently).
he did crowdsec for openwrt? oooh. i might have to look into that. I use crowdsec on a server i babysit. I love it for autobanning ppl knocking on the server.
I probably should have made my 'fantasy' clearer...
what i'm picturing is;
this "dns-takeover" was/is the trickiest thing with AGH... followed by data migration I suppose... if the mainUI gets yamil edit... they'd be the main two things troubling users
I was thinking about something like this, also... 
We have to do it ! 
But already so much in the "pipe" !
Having played with AGH and looked into some of the issues reported. Currently until they fix some of them I cannot really recommend the best option which would be to install AGH and migrate all DNS/DHCP directly to AGH and pull it from OpenWRT. That would be the cleanest and far easiest way.
AGH team has even said they need to do much more work on dnsmasq and subsystems to make them workable. (honestly i do wonder if pulling in OpenWRTs work to replace some of their current dnsmasq/dhcp setup would be faster and better.)
My compromise was to cloak/hide OpenWRTs dns but leave it active/accessable for fallback and let OpenWRT handle DHCP and IP Assignments (cos AGHs is... bluntly. a shitshow. Again it is stuff planned to be looked at / sorted in 108 but some of what is required is only wishlist at present rather than must fix.)
Having OpenWRT forward to AGH is a simpler option but downside to that is the loss of statistics. (OpenWRT router is single source for all your requests and thus you don't get client breakdowns or the ability to setup different DNS requirements for clients)
If i was more of a programmer maybe i could work out how to insert the best of AGH into OpenWRT or even port OpenWRTs internals to replace some of AGHs mess would make things easier. This being said however, I do feel that AGH is a work in progress and its bloomed in spec from what they planned.
What i do love is AGH once installed makes it VERY easy to maintain and do blocklists, filters and DoH. Instead of messing with dnsmasq, stubby or other plugins you just drop in AGH and its one place does the lot. There is no way in hell i'm going back to unfiltered internet on a crap ISP router.
Also @erdoukki I will be hopefully testing out crowdsec once i get my R4S fully working (I'm just playing with it at present due to lack of dedicated VDSL modem.) At which point having crowdsec will allow me to do the "witness the power of this fully operational deathstar". Sadly no way in hell i can run that on the HomeHub5 due to its tiny ram and disk space. (I took a quick look and just the world lists for ip geolocation are 60mb.)
A long time ago i used to run Smoothwall and Snort filters. I do miss the whole sinkholing attackers on the net. Tarpit SSH deamons were fun too.
108 will bring a few upgrades to this. They are aware and issues are filed on changing default setup values (aka once u setup you cannot change them without manual edits) and user and password changes (you cant at present unless you edit the yaml file).
They appear to have properly fixed the stats issues. (basically stats db would get corrupted/imported between versions badly and you'd have to purge the file to get AGH back on its feet again) The issue with that was... it soaked all CPU cycles and thus made recovery... /interesting/ unless u had an open SSH session.
The non broken bits of their beta panel are promising thou and will make some nice additions.
I maybe need to write up some more issues for them and work through them. I stopped doing that once i got 107 stable enough i dont have to touch it anymore.
(edit)
I think i'll try look through things later this week and take some time to update this thread and look into exactly where they are going with AGH. Something definately needs doing about that horrible 104 openwrt package however. I am aware however that while OpenWRT did up the limits for to drop the 4mb/32mb routers that AGH is a bit of a beast. Default logging out of the box for OpenWRT routers should be set to minimal logging and space usage to avoid out of space issues and thus the inablility to autoupdate. Maybe some sort of script that pares down logs after a while and removes older backup copies? Query db after 3wks hit 21mb and that will be an issue for littler routers.
hmm. Yes.
12days running
AGH binary? 35mb
stats and query db 11mb
filters? 16mb
and another 35mb in AGH backup of previous version
that is not inconsiderable. And something that smaller routers will not manage lightly.
My HH5 has 128mb of ram and just about manages 100k of lists. (i started getting OOMs when i hit 140k)
(edit)
bugger. Seems they have bounced this to 109 release.
thats just one of the things that makes the need for OpenWRT to handle DHCP and AGH home only the DNS. (One improvement i asked for was the ability to properly select interfaces you serve DNS on as by default you could only pick ONE interface or ALL interfaces. ALL ment that it would server dns on your WAN interface (or DSL) which is not advisable.) And yes... yet ANOTHER reason you have to manually edit the yaml file.
However, if I install AdGuard Home and do not configure any settings through LuCi, I will not be able to manage AdGuard Home. openWRT will refuse me to connect to the Dashboard of AdGuard Home.
install AGH and move its management port to 8080 instead of port 80.
If u read further back in the thread i've done a number of posts explaining how i did it and the changes to make.
In my experience, the best way to add AdGuard Home to OpenWrt is to use the installer script and install the most recent beta from the AdGuard Home site. As mentioned above, do not use the existing OpenWrt package, it's outdated.
To make it easy to integrate with dnsmasq, before installation change dnsmasq port to 5353, restart dnsmasq, then run the installation script. This will install AdGuardHome with DHCP disabled by default, and have AdGuardHome DNS server use the default DNS port 53. After the installation script is run, finish config from port 3000 and set the administration port to 8080.
Before installation, it's important to read the following in full, otherwise you risk making wrong choices in the config process: https://github.com/AdguardTeam/AdGuardHome#getting-started
YMMV
I've used the split dnsmasq config for quite a while now for running a "kid safe" network. The IP network is completely separated. This works just fine.
I thought I'd try the AdGuard Home way of parental controls, not to control, but to shield some sites for younger eyes and let's face it, not all of us can distinguish a phishing attempt from the real thing.
Anyway, I've got a USB stick mounted, installed AGH on that and set it up to run as a DNS server for all clients on the network. I now have one single ipv4 network for all clients, including the one for my kids, so they are not on a separate ipv4 network anymore. In order to filter the right clients, I added clients in AGH. I'm tried AGH's DHCP server, but I can't edit, only delete and add new reservations. But, as I have just learned, if you run a lot of Apple devices, mainly the iPhones and iPads, the DHCP reservations are kind of a bummer.
Apple's default behavior on WiFi networks is to spoof a randomly generated MAC address, so the owners of the WiFi network are unable to track your activity based on a MAC address... I haven't discovered the limits of that privacy feature yet, but if I disable using a private MAC address I get this annoying message about a privacy warning on the Apple device in question...
So you can imagine that setting and actually trusting the MAC address as DHCP reservation for Apple devices is not a set and forget thing, on any DHCP server.
So far the clients in AGH based on MAC address and specific filtering is not a bulletproof method. Whether you set AGH as DHCP server, or let dnsmasq hand out fixed IP addresses based on DHCP reservations and use those fixed IP addresses in AGH to identify clients.
But, then there's IPv6... Identifying clients on fixed IPv4 addresses is kinda bulletproof except for Apple's privacy option. On IPv6 there's no telling how to identify with which IPv6 address a client will go on the Internet. It might be one of your ULA addresses OpenWRT hands out, or a public IPv6 address from your provider.
Any clues on how to tackle specific clients in a trustworthy manner to enable filtering with AGH? Because I do like it.
i havent used AGH DHCP. It badly needs extra work. I do use OpenWRTs DHCP however.
Android and Apple both do privacy but you can "trust" a home network and tell it not to use MAC randomization. (i dont have any apple devices so i dont know how you do that bit)
Ok so apple call it Private addresses.
you can edit your reservations on AGH... if you edit the yaml file which isnt ideal.
That you need to set by changing your IPv6 settings.
You need to set it so your router hands out your ISP v6 ips and doesnt auto generate its own.
you need a duid to reserve ipv6
I used the script you provided to install AGH. After installation, I still cannot enter AGH from Port 3000.
I have been tackling this in my own home network with AGH and filtering based on MAC address. From my experience so far with that Private Address feature in iOS, currently it generates the MAC address based on the wireless network SSID. So for example, if you have a network SSID of OpenWrt-2.4, it will always keep that same randomly generated MAC on that network. It will only change the MAC if you change the SSID. Also in AGH, you can create a client group that contains multiple MAC addresses for kids. You can add the regular device MACs and also the private MACs.
It is possible that Apple could randomize the MAC addresses even further (in future iOS updates), but now it is just dependent on the SSID.
I have adapted my whole KidSafe setup into AGH now. Different client groups for adults, different client group for each child, etc. I have Cloudflare DNS as upstream for the adult devices and OpenDNS Family Shield as upstream DNS for the KidSafe client groups. AGH is incredibly flexible once you get used to it.
I ended up dropping the two instances of dnsmasq that I was using with a similar KidSafe setup. I have dnsmasq completely disabled now and only AGH handling all DNS and DHCP. The only way to do MAC filtering on AGH is by using it as DHCP server, otherwise it cannot get MAC by forwarding from dnsmasq to AGH. That's why I only use AGH now for both DNS and DHCP.
did you remove the old AGH install?
what output did you get when you installed the new AGH?
The way I uninstalled AGH is to re-flash openWRT.
There is an error "udhcpc: no lease, failing"
can you post the output when you ran the install script? Without any info its kinda hard to diagnose issues.
