Adblock-fast: ad-blocking service for dnsmasq, smartdns and unbound

[odhiambo]

I am also seeing this

root@DL-WRX36:/var/run/adblock-fast# /etc/init.d/adblock-fast dl
tail: can't open '/tmp/adblock-fast_tmp.XXnEDloL': No such file or directory
tail: no files
[DL] Config  Update:  cdn.jsdelivr.net [✗]
Starting adblock-fast 1.1.2-1...
[DL] Blocked File: cdn.jsdelivr.net [✗]
ERROR: failed to create /var/run/adblock-fast/dnsmasq.servers file!
adblock-fast 1.1.2-1 failed to start: Downloading...!
root@DL-WRX36:/var/run/adblock-fast#

On the luci UI, I see this:

[stangri]

@wjkk

When I right click on images that didn't load and choose 'open image in other tab' the image do not load and I get ERR_CONNECTION_REFUSED (sometimes ERR_QUIC_PROTOCOL_ERROR) in the browser. The domain is https://encrypted-tbn1.gstatic.com/ which is not blocked by blocklist (I checked, then I even added it to allowed domains). Yet it do not load. Interesting is that if I wait for a couple minutes, the images will load and thumbnails behind *.gstatic.com domain wil load again. Other interesting thing is that after I allowed mentioned domain, and missing images started to not load, the domain was https://encrypted-tbn2.gstatic.com/ (not tbn1 like before).

I'd add the gstatic.com to the allowed domains and retest. Given the intermittent nature of the problem, maybe it has something to do with the upstream DNS? If not, are there any out of memory crashes in the system log?

@ganxy

The service works well, but the web UI seems not. Sometimes it will take a while to load it's web UI, and even got time out, and sometimes it will just take a second, unpredictably. I'm using your https-dns-proxy plugin two, it runs smoothly.

Try clearing browser cache. Having said that, I don't know what modifications ImmortalWrt has over vanilla OpenWrt, neither am I able to test adblock-fast on ImmortalWrt.

If you can run the following commands in CLI and see if any of them take unreasonably long to respond, that would be the first investigation step:

ubus -v list luci.adblock-fast
ubus -S call luci.adblock-fast getFileUrlFilesizes '{"name": "adblock-fast" }'
ubus -S call luci.adblock-fast getInitList '{"name": "adblock-fast" }'
ubus -S call luci.adblock-fast getInitStatus '{"name": "adblock-fast" }'
ubus -S call luci.adblock-fast getPlatformSupport '{"name": "adblock-fast" }'

@ganxy

I'm a China user, and the github/openwrt/jsdelivr is intermittently unaccessible for me, could it be the reason?

No, that should affect the functionality, but I was under impression that jsdelivr was not blocked in China, could you please clarify?

@phinn

Is there an issue with the latest version? Been using Adblock Fast for a long time now but never had this happen, even after restarting the service and a reboot it won't start on a new build from today. From LuCI page:

Weird, which OpenWrt version is that on? From CLI, can you post the output of:

ls -la /var/run/adblock-fast/
mkdir -p /var/run/adblock-fast/
touch /var/run/adblock-fast/dnsmasq.servers

@odhiambo

I am also seeing this

Same questions as above, thanks!

[phinn]

Just yesterday's snapshot, r26581. Those commands didn't do much to troubleshoot.

root@OpenWrt:~# ls -la /var/run/adblock-fast/
drwxr-xr-x 2 root root 40 Jun 9 15:43 .
drwxr-xr-x 9 root root 520 Jun 9 21:42 ..
root@OpenWrt:~# mkdir -p /var/run/adblock-fast/
root@OpenWrt:~# touch /var/run/adblock-fast/dnsmasq.servers
root@OpenWrt:~# ls -la /var/run/adblock-fast/
drwxr-xr-x 2 root root 60 Jun 10 20:08 .
drwxr-xr-x 9 root root 520 Jun 9 21:42 ..
-rw-r--r-- 1 root root 0 Jun 10 20:08 dnsmasq.servers
root@OpenWrt:~#

Same errors are on LuCI page: Failed to start

[stangri]

@phinn

Just yesterday's snapshot, r26581. Those commands didn't do much to troubleshoot.

My guess would be something has changed with the user the procd init scripts run from and/or default jail for procd scripts in the recent snapshot and the init script doesn't have access to the /tmp/ and /var/run/ anymore.

I don't have time to investigate this at least until the end of this week if not the next. If someone can figure out/let me know what's happening, I might be able to implement the fix quickly tho.

[ganxy]

If you can run the following commands in CLI and see if any of them take unreasonably long to respond, that would be the first investigation step

I add this blocklist https://raw.githubusercontent.com/Cats-Team/AdRules/main/dns.txt and then getFileUrlFilesizes takes obviously longer to respond. Does that mean a user-add rule will be checked through Internet every time, and when the githubusercontent is inaccessible for me, it runs time out?

No, that should affect the functionality, but I was under impression that jsdelivr was not blocked in China, could you please clarify?

In fact, github/openwrt/jsdelivr are not literally blocked but unregistered in China. I think some of their servers are blocked while most of which are still reachable. They are usually accessible, and if not, we can just wait one or two minutes to have a retry and the DNS may respond an other unblocked server. Google/Facebook/twitter are definitely blocked, so that they are total unreachable unless via vpn.

[stangri]

@ganxy

I add this blocklist https://raw.githubusercontent.com/Cats-Team/AdRules/main/dns.txt and then getFileUrlFilesizes takes obviously longer to respond. Does that mean a user-add rule will be checked through Internet every time, and when the githubusercontent is inaccessible for me, it runs time out?

Thank you for bringing it up and elaborating on the issue.

There's a code which tries to determine the file size of all added block-lists by downloading first 512 bytes or so if I remember correctly. The sizes are then displayed in the WebUI so that users can decide which block-lists they can enable without running out of memory on the router.

Obviously, the assumption was that you're only adding the block-lists to the config which are accessible to you, I'll try to play with that code to see what can I improve so it fails faster for the links which are inaccessible.

[ganxy]

Thanks for reply and the following works.
I suggest that you might modify the process flow to let the web UI load first and then determine and refresh the file size of every blocklist.

There's a code which tries to determine the file size of all added block-lists by downloading first 512 bytes or so if I remember correctly.

Does this all added block-lists mean all and only the blocklists added by user himself or both package-provided and user-added blocklists? When I say the Cats-Team Rule will make the getFileUrlFilesizes taking obviously longer to respond, I mean even the one and only rule had been added and size determined, getFileUrlFilesizes will still take longer to respond every time when it's called. So it seems that user-added rules are always being unfairly treated from the package-provided ones, which is quite logically wired. I don't think it's a result of inaccessible problem, because there are other package-provided github raw rules such as the AdguardTeam ones.

[stangri]

@ganxy

I mean even the one and only rule had been added and size determined, getFileUrlFilesizes will still take longer to respond every time when it's called.

No, if the size is known, it's not being refreshed on getFileUrlFilesizes. Realistically, unless you're adding unavailable to you lists, it all works very fast. You're welcome to contribute any code you may consider improvement to the original source repo.

[ganxy]

No, if the size is known, it's not being refreshed on getFileUrlFilesizes .

I find that /etc/config/adblock-fast will not update the file size that the web UI has known. Does this only happen to me?

I edit the config file and give it a random option size, then everything runs well now.

[stangri]

Thanks for spotting and reporting this! Version 1.1.2-2 (in my repository) contains the fix for the file size not being stored in config. You'll need to update both principal package and the luci app.

[stangri]

I've had another theory, maybe just the /tmp had gotten smaller (due to a bigger kernel or something). @odhiambo @phinn can you try with only the smallest list and see if that works?

[phinn]

Unchecked everything, restarted the service, picked the smallest block list on the list 10.89 KB at the bottom. Same results it won't start:

Status
Version 1.1.2-1 - Failed to start.

Service Errors
Failed to download https://cdn.jsdelivr.net/gh/hoshsadiq/adblock-nocoin-list/hosts.txt!
Failed to create '/var/run/adblock-fast/dnsmasq.servers' file!
Failed to create block-list or restart DNS resolver!
Errors encountered, please check the README!

[stangri]

Thank you for testing so quickly!

If you don't mind testing a few more theories, can you please run and post the output of:

. /etc/init.d/adblock-fast
R_TMP="$(mktemp -u -q -t ${packageName}_tmp.XXXXXXXX)"
touch "$R_TMP"
echo 11111 > "$R_TMP"
ls -la "$R_TMP"
. /etc/rc.common
load_validate_config load_environment
echo "$dl_command"

[phinn]

Can you help me run that? It's not doing anything, just getting errors, "package name is read only" I tried to run it as an executable shell script too and nothing:

root@OpenWrt:/# . /etc/init.d/adblock-fast
"
touch "$R_TMP"
echo 11111 > "$R_TMP"
ls -la "$R_TMP"
. /etc/rc.common
load_validate_config load_environment
echo "$dl_command"-ash: readonly: line 35: packageName: is read only
root@OpenWrt:/# R_TMP="$(mktemp -u -q -t ${packageName}_tmp.XXXXXXXX)"
root@OpenWrt:/# touch "$R_TMP"
root@OpenWrt:/# echo 11111 > "$R_TMP"
root@OpenWrt:/# ls -la "$R_TMP"
-rw-r--r--    1 root     root             6 Jun 16 17:35 /tmp/adblock-fast_tmp.XXeDeHbj
root@OpenWrt:/# . /etc/rc.common
-ash: .: line 123: : not found
root@OpenWrt:/# load_validate_config load_environment
-ash: uci_load_validate: not found
root@OpenWrt:/# echo "$dl_command"

root@OpenWrt:/#

[stangri]

@phinn

Can you help me run that? It's not doing anything, just getting errors, "package name is read only"

You only have to do the paste in CLI once, if you do it more than once you'll get that error.

I remember seeing some issues with the mbedtls errors when trying to access https in the snapshots, maybe that's an issue. The solution I've seen was to rebuild curl with OpenSSL dependency instead.

If you run something like curl --insecure https://cdn.jsdelivr.net/gh/hoshsadiq/adblock-nocoin-list/hosts.txt does it show the output or does it produce an error?

Link to the issue: https://github.com/openwrt/packages/issues/24365

[phinn]

root@OpenWrt:~# curl --insecure https://cdn.jsdelivr.net/gh/hoshsadiq/adblock-nocoin-list/hosts.txt
curl: (35) ssl_handshake returned - mbedTLS: (-0x2700) X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
root@OpenWrt:~#

---

For the regular Adblock package - very few of the blocklists work there either:

Mon Jun 17 20:00:36 2024 user.info adblock-4.1.5[1999]: blocklist with overall 0 blocked domains loaded successfully (GL.iNet GL-MT6000, OpenWrt SNAPSHOT r26637-05aec66d53)
Mon Jun 17 21:49:55 2024 user.info adblock-4.1.5[18261]: adblock instance started ::: action: reload, priority: 0, pid: 18261
Mon Jun 17 21:49:55 2024 user.info adblock-4.1.5[18261]: download of 'adaway' failed, url: https://raw.githubusercontent.com/AdAway/adaway.github.io/master/hosts.txt, rule: /^127\.0\.0\.1[[:space:]]+([[:alnum:]_-]{1,63}\.)+[[:alpha:]]+([[:space:]]|$)/{print tolower($2)}, categories: -, rc: 55, log: curl: (55) Error
Mon Jun 17 21:49:55 2024 user.info adblock-4.1.5[18261]: download of 'adguard' failed, url: https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt, rule: BEGIN{FS="[/|^|\r]"}/^\|\|([[:alnum:]_-]{1,63}\.)+[[:alpha:]]+[\/\^\r]+$/{print tolower($3)}, categories: -, rc: 55, log: curl: (55) Error
Mon Jun 17 21:50:00 2024 user.info adblock-4.1.5[18261]: blocklist with overall 4609 blocked domains loaded successfully (GL.iNet GL-MT6000, OpenWrt SNAPSHOT r26637-05aec66d53)

[stangri]

You live by the snapshots, you adblock by the snapshots.

Seems like a serious issue with libmbedtls, if you can, build curl with openssl dependency and use that.

If your router is supported in the latest release, I'd roll back to 23.05.3.

[phinn]

Yes it is, this is something that must have happened in main in last couple weeks, since I just had a good working snapshot recently. But yes, you're right might have to roll back to 23.05.3 if I could bear going back to kernel 5.15

Thanks for helping, I posted some results to that bug report too.

[egc]

I recently had the same problem with curl (not related to adblock etc), I rebuild curl with OpenSSL and it worked again.

[stangri]

Seems the fix has been merged yesterday, the new curl builds should be up in snapshots repo now. AFAIR it should be curl 8.8.0-2.