# /etc/init.d/adblock query checkip.amazonaws.com
sh: out of range
TestAdblock: Calling f_query checkip.amazonaws.com
TestAdblock: Called f_query
TestAdblock: Before While..
:::
::: domain 'checkip.amazonaws.com' in active blocklist
:::
+ checkip.amazonaws.com
Edit #1: Additional testing
I've drilled it down to the rc_procd function in /etc/rc.common but can't find what is triggering the error ahahaha
# /etc/init.d/adblock query checkip.amazonaws.com
TestAdblockInit: Before runtime checks...
TestAdblockInit: After runtime checks...
TestAdblockInit: init.d:: calling rc_procd '/usr/bin/adblock.sh' query 'checkip.amazonaws.com'
TestRCCommon: Called rc_prcd..
TestRCCommon: Running procd_open_service
TestRCCommon: Show @:: '/usr/bin/adblock.sh query checkip.amazonaws.com'
sh: out of range
TestAdblock: Calling f_query checkip.amazonaws.com
TestAdblock: Called f_query
TestAdblock: Before While..
Didn't help in tracing because the sh: out of range error is being triggered even before f_query was called.. i'll do more testing later and see if I can pinpoint when it's actually being triggered
Thanks again for the assistance.. found the culprit and entirely my fault.. I accidentally merged a test code on my builds which I though I have already removed last year
I've had the same issue with 24.10.2. Resolved it with:
uci set adblock.global.adb_lookupdomain='google.com'
uci commit adblock
/etc/init.d/adblock restart
Now adblock is running like a charm again.
Update: I noticed it is because of my dnsmasq setup. I was using a resolv file per vlan. Now switched to noresolv and upstream dns servers per vlan, and after that change, localhost (f.e. localhost.vlan_domain) was resolvable again. Maybe useful additional info for anyone having this issue.
Since the last major update (version 4.4.x), I have encountered two significant issues:
The option to bypass backups has been removed. This is a major concern for routers with limited RAM, as it can lead to performance problems. I (maybe a lot) would appreciate it if you could consider adding this option back.
Occasionally, blocked domains are accessible despite the AdBlock service showing no errors and remaining in a 'running' status. Restarting the service does not resolve the issue; only rebooting the router restores functionality and re-establishes domain blocking. This behavior has not occurred in previous versions.
I wanted to follow up on my previous message regarding the issues I encountered after the last major update (version 4.4.x). Upon further investigation, I realized that the intermittent accessibility of blocked domains was due to Firefox's default secure DNS setting. When enabled, Firefox sometimes opts for encrypted DNS, which can bypass the AdBlock service. Interestingly, rebooting the router seems to prompt Firefox to revert to normal DNS temporarily, but it eventually switches back to encrypted DNS. Turning off "Enable DNS over HTTPS" resolves the issue.
That said, I would still appreciate it if you could consider adding the option to bypass backups. Currently, I am using /dev/null as the backup location, but this approach causes gzip to run, consuming unnecessary CPU and RAM resources.
Adding following domains in "Edit Blocklist" tab of Adblock UI will switch off DoH setting in Firefox and Safari (unless it is in Enforce mode). Those are so called "canary" domains:
Openwrt 24.10.2, adblock 4.4.2-r3 and blocklists backup on USB stick.
Just realised my old chronjob /etc/init.d/adblock restart doesn't update blocklists anymore (same as manually executing the command). Intended or some bug?
Firefox utilizes Cloudflare's DNS over HTTPS (DoH). I've observed this in my DNS request captures, and in the about:networking#dns section, it shows that it uses the endpoint https://mozilla.cloudflare-dns.com/dns-query. However, managing and maintaining these domains isn't ideal, as users can simply toggle the feature off and on as needed. That said, I still hope the developers will consider adding an option to bypass the need for backups.