How about DHCP? To my knowledge dnsmasq provides both name resolution and IP address serving (as well as static leases). Do you mean I would have to have dnsmasq for DHCP, adguard for name resolution and Adblock to get rid of unwanted ads?
Is there a particular order in which I would go about installing and configuring the 3 services?
I mean, do I need to install one package first, then set it up, reboot then go about setting the others, in a similar fashion, or should I simply download the two optional packages, then simply configure everything from the Luci Interface in a single shot?
Thanks for all your previous input. I have installed both Adblock and AdGuardHome. I've setup AdGuardHome from the setup page at [myrouter-ip-address]:3000 to provide DNS name resolution from port 5353. But I'm not sure how I make the router itself use this instance as it's DNS server for name resolution.
I've tried all Diagnostics utilities from Luci Network/Diagnostics, and found out that name resolution is still working, but seem to be getting data from the original dnsmasq that apparently is still operational from port 53.
I'm hesitant to change the port from Luci Network/DHCP and DNS, as per image below. Is this the correct place to make the necessary change? Looks to me that this would instead change the original dnsmasq name resolution conflicting with the port I've mentioned above for AdGuardHome...
EDIT: I don't know if I got it right, but I added list server '192.168.1.1#5353' to the dnsmasq section of /etc/config/dhcp and now it seems that it's working like this:
system dns server: original dnsmasq existing from default OpenWrt installation, on port 53.
dnsmasq then forwards queries to AdGuardHome's dns server on the same machine, but on port 5353.
Questions:
a) Am I on the right track, or should I change anything?
b) How about DHCP? Is it still being taken care of by the original dnsmasq instance?
AdGuard is in the opkg repositary however it is v104. Adguard via install script is on 107. There are some substantial issues solved between them and some outstanding issues.
TLDR? (too long didnt read)
AdGuard is a nice blocker much like Adblock and also Pihole. You can pretty much get similar blocking from all 3 by using good lists.
(:edit: Beware when using lots of lists on small memory routers. DNS services WILL crash when they run out of mem and get process reaped)
Adguard however if you configure it to use their DNS service can offer some upstream blocking as well.
Adblock is fairly simple with stats.
Pihole and AdGuard give you more stats.
AdGuard /can/ do dhcp. however at present, I wouldnt use it that way. There are some fairly substantial deficiencies with their implementation and OpenWRT has improved DHCP v6 handling. Adguard has not. Best of both worlds would be for AdGuard to pull some of those fixes into their tree. They freely admit their DHCP needs work and merging but its "on the list" to do.
:edit: This is an important point. AdGuard has a significant issue in that uses the tmp folder. This is WIPED when you reboot your router. As such there needs to be a patch for Adguard or a better configureation setup (the DHCP leases and reservations are held there and you will have to redo reservations everytime you reboot the router. Unless you use a usb stick and a tmp folder redirect. This may not be possible on all routers)
:edit2: Ability to edit "DHCP static leases" entry after its saved · Issue #1700 · AdguardTeam/AdGuardHome (github.com) < the dhcp lease issue.
This is how i configured AdGuard using RC3. Just be aware that the opkg version is 104. Latest Edge version of AdGuard is 107. So i'd say use their script to install off their site instead of installing the opkg version.
Making it so you block with AdGuard and use dnsmasq/ohdhcp for the backend.
However. if u just suppliment the lists that adblock has with extra lists you should be able to do the same.
What differs however is that by using adguard you can do DoH and secure dns all in one package and also set multiple upstreams fairly easily.
Do you think I could go out and simply install the script version (107) on top of the packaged version (104)? Or, should I first remove the packaged version?
I tried installing over top and ran into issues. Probably wiser to remove the packaged version and reboot. Then install the new script version. They install to different locations anyway. I will be rebuilding my router to try again as I'm fairly sure the weird issues i'm having are due to the mixed issues.
:edit: i'm using a BT Hub 5 with only 128mb of ram. The new beta stats / dashboard page on port 3001 is giving me 404 errors or not loading pages. but the old dashboard on port 8080 (where i installed it) is working ok. I'm unsure if this is because of mixed config pages or something else. Thus why i'm doing clean install and trying the edge 107 version from clean install and then examining the yaml file it will create. They appear to be "agile" in development. aka, patch and ask ppl to try it out. Thus why the edge builds are most likely to be bug fixed. I have found out that the DHCP lease issue is due to be patched in 108. I'm interested to see how they will fix it and if it will work with OpenWRT nicely or if i will have to request fixes.
they appear to have a beta dashboard that is experimental. It installed on port 3001 for me. I've just reinstalled my router and was checking the install for the regular release which is currently v0.106.3.
This version doesnt have that dashboard but i'm in the middle of bugreporting an issue with the install script and i'll have a go with the latest release in a bit.
I did notice this however. AdGuard Home will be installed into /opt/AdGuardHome
This resolves some of the issues with the /tmp being wiped on reboot but may end up with out of space issues as the queries log fills up. I think just having some sensible values for logging should deal with that for OpenWRT users.
How bizarre... I have not installed the latest beta. I have just verified from the 8080 dashboard and the script installed the last released version, not the beta as I thought before. Sorry for my previous misleading post. I've tried to edit my previous message to change from beta to released on last paragraph, but it seems I cannot anymore.
The beta port is the "new" dashboard. It was also the one i was having issues with when i last tested but i was testing with an over the top install and i didn't know if that was the reason. Now i have a clean install and can poke and play and break more things
I do have a concern with how it installs however. Its causing me some thought as it really requires a re-write or a better way of doing the interface selection.
Right now if you tell it "All Interfaces" it binds to 0.0.0.0 however this then means it will serve DNS on your PUBLIC interface (which really isn't advisable).
it would be better to maybe select which interfaces rather than do an ALL or just one.
Mostly because you want DNS on loopback (127.0.0.1), your ip4 lan (192.168.1.1) and your ip6 lan (::1) but you don't want it on the public interfaces.
Also there is NO Way at present to edit these values once it has done its initial setup other than to manually edit the yaml file which isn't ideal for newer users. Maybe some sort of initial config page needs adding or the install process adjusting. I'm going to have a think about things and see if i can write up something to report as an issue for their team.
So. The beta dashboard is nice looking however. Still broken. It will give you the main dashboard pages instead the proper subpages. Opening the sublinks gets a 404.
Also given my router is a bt hub 5 and only has 128mb of memory...
I feel the stats pic from the bottom of the beta page may be inaccurate...
Mine shows 0 for beta_bind_port. I suppose it's because its release, not beta.
Yes, there should be a way of maybe re-run the initial setup to change settings in case the user changes his/hers mind after initial setup. Have you tried renaming the yaml file to something else and restarting the service to see if it enables the setup page again?
At least this should allow users to compare yaml files side to side.
i wouldnt say it beta. More like alpha. I am going to have a look and see if they have any notes or explainations about the beta pages and if there are issues filed on them.
regarding the yaml file. i just edit it to change values. I acutally install it on port 5353 then swap openwrts dnsmasq dns port from 53 to 5353 and swap Adguards from 5353 to 53. This way instead of it being an upstream feed for openwrt its the acutal source dns and thus can give me proper statistics instead of the 127 loopback that openwrt uses.
so like this.
Clients > Openwrt > Adguard via 127.0.0.1 upstream feed > DNS
Port change and it becomes
Clients > Adguard > DNS
with OpenWRT running in background on port 5353 as a "backup" dns (i have it set to use googles dns) My Adguard uses cloudflare. Just makes double checking which dns is in use easy. Just do a dns leak test and see which is reported.