Adblock is not downloading the host lists on router reboot

Installing and Using OpenWrt
1

Subject: Adblock Not Loading Host Lists on Reboot

Hi everyone,

I hope you can help me with this issue. I’ve been trying to troubleshoot this with ChatGPT for days but haven’t had any luck.

When I manually reload Adblock, everything works fine. The blocked domains list loads, and everything functions as expected. However, after a reboot, the status shows that 0 blocked domains are active, and it seems the host lists are not being loaded automatically.

Here are some of the terminal outputs I’ve gathered:

Adblock status after manual reload:

root@OpenWrt:~# /etc/init.d/adblock status
::: adblock runtime information
  + adblock_status  : enabled
  + adblock_version : 4.2.3-2
  + blocked_domains : 168387
  + active_sources  : adguard, android_tracking, stevenblack
  + dns_backend     : dnsmasq (-), /tmp/dnsmasq.d
  + last_run        : reload, 0m 25s, 380 MB available, 1436 KB max. used, 2025-01-13T17:28:25+00:00

Adblock status after reboot:

root@OpenWrt:~# /etc/init.d/adblock status
::: adblock runtime information
  + adblock_status  : enabled
  + adblock_version : 4.2.3-2
  + blocked_domains : 0
  + active_sources  : adguard, android_tracking, stevenblack
  + dns_backend     : dnsmasq (-), /tmp/dnsmasq.d
  + last_run        : start, 0m 17s, 410 MB available, 1432 KB max. used, 2025-01-13T17:28:33+00:00

It appears that the Adblock lists are not being loaded automatically after the reboot.

Can anyone help me understand why Adblock isn’t loading the host lists at boot? Please let me know what additional terminal outputs you’d like to see to help investigate this further.

Thanks in advance for your assistance!

2

Please post your adblock config (/etc/config/adblock).

2 Likes
3 

config adblock 'global'
	option adb_enabled '1'
	option adb_debug '1'
	option adb_forcedns '0'
	option adb_safesearch '0'
	option adb_dnsfilereset '0'
	option adb_mail '0'
	option adb_report '0'
	option adb_backup '1'
	option adb_dns 'dnsmasq'
	option adb_fetchutil 'curl'
	list adb_sources 'adguard'
	list adb_sources 'android_tracking'
	list adb_sources 'stevenblack'
	list adb_stb_sources 'alternates/fakenews-porn-social/hosts'
	list adb_stb_sources 'alternates/gambling-only/hosts'
4

Define a startup trigger and a trigger delay, e.g. ...

General Settings:
image

Additional Settings:
image

2 Likes
5

Firstly, I want to extend a heartfelt thank you to everyone who has offered their assistance so far. Your willingness to help and support is truly appreciated.

I've set the Startup Trigger Interface in Adblock to "wan" as suggested, and added a Trigger delay @ 30 but unfortunately, it hasn't resolved the issue. I've been struggling with setting up OpenWrt, and it's starting to wear me down. This problem has been particularly troublesome.

I'm grateful for any further advice or solutions you can provide to get Adblock working properly. Any insights or suggestions are welcome, and I'm hopeful that with your help, I'll be able to overcome this hurdle.

Thank you in advance for your continued support.

	option adb_enabled '1'
	option adb_debug '1'
	option adb_forcedns '0'
	option adb_safesearch '0'
	option adb_dnsfilereset '0'
	option adb_mail '0'
	option adb_report '0'
	option adb_backup '1'
	option adb_dns 'dnsmasq'
	option adb_fetchutil 'curl'
	list adb_sources 'adguard'
	list adb_sources 'android_tracking'
	list adb_sources 'stevenblack'
	list adb_stb_sources 'alternates/fakenews-porn-social/hosts'
	list adb_stb_sources 'alternates/gambling-only/hosts'
	option adb_trigger 'wan'
	option adb_triggerdelay '30'
6

Check logs on boot, there can be a race condition on discovering the WAN interface detection causing a things to not start correctly, ergo manual works when everything it up and running.

1 Like
7

Please provide complete adblock debug logs from a startup.

1 Like
8

logread | grep adblock

Mon Jan 13 18:13:06 2025 user.debug adblock-4.2.3-2[3568]: f_fetch  ::: fetch_util: /usr/bin/curl, fetch_parm:  --connect-timeout 20 --fail --silent --show-error --location -o
Mon Jan 13 18:13:06 2025 user.info adblock-4.2.3-2[3568]: adblock instance started ::: action: start, priority: 0, pid: 3568
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_uci    ::: config: dhcp, change:
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_uci    ::: config: firewall, change:
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: iplist, mode: iplist, cnt: 0, in_rc: 0, out_rc: 0
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: blacklist, mode: blacklist, cnt: 0, in_rc: 0, out_rc: 0
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: whitelist, mode: whitelist, cnt: 1, in_rc: 0, out_rc: 0
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: adguard, mode: restore, cnt: 0, in_rc: 4, out_rc: 4
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: android_tracking, mode: restore, cnt: 0, in_rc: 4, out_rc: 4
Mon Jan 13 18:13:07 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: stevenblack, mode: restore, cnt: 0, in_rc: 4, out_rc: 4
Mon Jan 13 18:13:12 2025 user.info adblock-4.2.3-2[3568]: download of 'android_tracking' failed, url: https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/android-tracking.txt, rule: /^([[:alnum:]_-]{1,63}\.)+[[:alpha:]]+([[:space:]]|$)/{print tolower($1)}, categories: -, rc: 6, log: curl: (6) Could not resolve host: raw.githubusercontent.com
Mon Jan 13 18:13:12 2025 user.info adblock-4.2.3-2[3568]: 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: 6, log: curl: (6) Could not resolve host: adguardteam.github.io
Mon Jan 13 18:13:17 2025 user.info adblock-4.2.3-2[3568]: download of 'stevenblack' failed, url: https://raw.githubusercontent.com/StevenBlack/hosts/master/, rule: /^0\.0\.0\.0[[:space:]]+([[:alnum:]_-]{1,63}\.)+[[:alpha:]]+([[:space:]]|$)/{print tolower($2)}, categories:  alternates/fakenews-porn-social/hosts alternates/gambling-only/hosts, rc: 6, log: curl: (6) Could not resolve host: raw.githubusercontent.com
Mon Jan 13 18:13:17 2025 user.debug adblock-4.2.3-2[3568]: f_list   ::: name: -, mode: merge, cnt: 0, in_rc: 4, out_rc: 0
Mon Jan 13 18:13:23 2025 user.debug adblock-4.2.3-2[3568]: f_dnsup  ::: dns: dnsmasq, cache_cmd: -, lookup_cmd: /usr/bin/nslookup, lookup_domain: example.com, restart_rc: 0, dns_flush: 0, dns_timeout: 20, dns_cnt: 0, in_rc: 0, out_rc: 0
Mon Jan 13 18:13:23 2025 user.info adblock-4.2.3-2[3568]: blocklist with overall 0 blocked domains loaded successfully (Linksys MR8300 (Dallas), ipq40xx/generic, OpenWrt 23.05.5 r24106-10cc5fcd00 )
Mon Jan 13 18:21:16 2025 daemon.err uhttpd[1848]: [info] luci: accepted login on /admin/services/adblock/overview for root from 192.168.1.33

I will add that I tried to use uclient-fetch, curl, wget and aria2c as a download utility. All of them fail to download at start but are perfectly fine to download lists manually.

dmesg | grep adblock gives nothing

9

check that 'wan' is really the correct interface (it was just an example). Also raise the trigger delay, e.g. to 60 seconds - esp. on pppoe internet connections. Good luck.

1 Like
10

I only have lan, wan and wan6 specified there.

Screenshot from 2025-01-13 18-49-13
Screenshot from 2025-01-13 18-49-13447×180 11.7 KB

cat /etc/config/dhcp

	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'  # enable for dial on demand
	option localise_queries '1'
	option rebind_protection '1'  # disable if upstream must serve RFC1918 addresses
	option rebind_localhost '1'  # enable for RBL checking and similar services
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'  # bind to & keep track of interfaces
	option localservice '1'  # disable to allow DNS requests from non-local subnets
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'
	list server '127.0.0.1#5453'
	list server '::1#5453'
	option noresolv '1'
	option confdir '/tmp/dnsmasq.d'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

cat /etc/config/network

	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fda9:bdb7:54be::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config device
	option name 'lan1'
	option macaddr 'c4:41:1e:0d:de:78'

config device
	option name 'lan2'
	option macaddr 'c4:41:1e:0d:de:78'

config device
	option name 'lan3'
	option macaddr 'c4:41:1e:0d:de:78'

config device
	option name 'lan4'
	option macaddr 'c4:41:1e:0d:de:78'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'wan'
	option macaddr 'c4:41:1e:0d:de:77'

config interface 'wan'
	option device 'wan'
	option proto 'pppoe'
	option username '******@aquiss.com'
	option password '***********'
	option ipv6 'auto'
	option peerdns '0'
	option dns '127.0.0.1'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option ip6assign '56'```
11

Thanks, that means 'wan' is correct. Derived from the adblock logs your DNS is not working at boot, e.g.:

Did you use stubby or other proxies? If so, disable this stuff until the usual things are working fine ...

1 Like
12

Thanks for your reply. Yes, I have been using Stubby for DNS-over-TLS (DoT) to connect to CZ.NIC's DNS servers. I configured Stubby on the router to use port 5453, as you can see in the logs and configuration. The goal was to have a secure and private DNS setup with DoT.

Stubby is running as expected, and I can see that the process is active.

The WAN interface is correctly set up, and DNS is resolving to 127.0.0.1 (which is the local Stubby instance). However, I am still facing the issue where Adblock's blocked_domains count is 0, even after increasing the delay. Stubby does not seem to be failing at boot based on the logs.

Could you suggest any further steps to isolate the issue?
I am not sure how to revert the DNS setup I made here without braking the internet connection.

cat /var/etc/stubby/stubby.yml

# Note: by default on OpenWRT stubby configuration is handled via
# the UCI system and the file /etc/config/stubby. If you want to
# use this file to configure stubby, then set "option manual '1'"
# in /etc/config/stubby.
resolution_type: GETDNS_RESOLUTION_STUB
round_robin_upstreams: 1
appdata_dir: "/var/lib/stubby"
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
idle_timeout: 10000
listen_addresses:
  - 127.0.0.1@5453
  - 0::1@5453
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
upstream_recursive_servers:
  - address_data: 193.17.47.1
    tls_port: 853
    tls_auth_name: "odvr.nic.cz"
  - address_data: 185.43.135.1
    tls_port: 853
    tls_auth_name: "odvr.nic.cz"
  - address_data: 2001:148f:ffff::1
    tls_port: 853
    tls_auth_name: "odvr.nic.cz"
  - address_data: 2001:148f:fffe::1
    tls_port: 853
    tls_auth_name: "odvr.nic.cz"
#upstream_recursive_servers:
#  - address_data: 2606:4700:4700::1111
#    tls_auth_name: "cloudflare-dns.com"
#  - address_data: 2606:4700:4700::1001
#    tls_auth_name: "cloudflare-dns.com"
#  - address_data: 1.1.1.1
#    tls_auth_name: "cloudflare-dns.com"
#  - address_data: 1.0.0.1
#    tls_auth_name: "cloudflare-dns.com"
13

As said before, your DNS takes too long ... raise the startup trigger to 60 or 90 seconds. And if you really need a stable DoT implemenation use unbound (standalone).

1 Like
14

Disabled stubby and set DNS directly to 1.1.1.1
No DoT, no proxy.
And the issue still persist. Also, I am at trigger 90 seconds. It does not download the lists after restart. If I restart AdBlock manually, it works. Go figure. This drives me crazy.

15

What is in /tmp/resolv.conf.d/resolv.conf.auto both now, and when it’s broken at boot time?

1 Like
16

It is correct now

# Interface wan
nameserver 1.1.1.1
nameserver 1.0.0.1
# Interface wan6
nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001

but it was

# Interface wan
nameserver 127.0.0.1
# Interface wan_6

a messing remains of stubby configuration.

Thank you guys, this solved all the issues I had. Now the IPv6 is working fine and AdBlock downloads the lists on reboot even with a default 2 seconds of delay.

Should I keep the 'Startup Trigger Interface' as wan or should I revert to unspecified as it was by default.

17

Great that you've fixed it - please keep the trigger.

1 Like
18

I wonder why do you need to use hosts files for adblocking? I may be wrong here, but to my understanding anything you can do with hosts, you can do with other formats, with difference being that hosts-based adblocking results in adblocked domains returning 0.0.0.0 (rather than NXDOMAIN), and the fact that hosts source files are typically not optimized, and if you want to optimize them then you need to enable TLD compression in adblock, which (to my understanding) is computationally expensive, so blocklists take much longer to load. This is not a critique. I would genuinely like to understand what are the benefits.

1 Like
19

Thank you for your response and for sharing your thoughts!

To provide some context, I am relatively new to OpenWrt and networking in general. Previously, I used hosts files locally on my client devices for adblocking. This required manual updates on each device, which was tedious and time-consuming. When I discovered that OpenWrt could handle this process at the router level for my entire network, I saw it as a great improvement and decided to give it a try. Automating updates and managing adblocking centrally for the whole network seemed like a significant upgrade over my previous setup.

I admit that I am not familiar with other methods or formats for adblocking beyond hosts files, which is why I would genuinely appreciate your insights. If there are better or more efficient approaches, I’d be very interested in learning about them. Could you please elaborate on the alternatives you’re suggesting and perhaps share some ready solutions or examples? Understanding what makes those methods superior in specific scenarios would be very helpful.

I’m open to feedback and further optimization based on your recommendations.

Thank you again for engaging in this discussion, and I look forward to your guidance!

20

Sure, but I'll start off saying that I am not an expert on adblocking and I do not know everything about it. A few months ago I more or less accidentally started to contribute to the adblock-lean project. At this point much of the code in adblock-lean is a product of my contributions, however all my contributions are focusing on improving the technical aspects of the code and the user interface. Conceptually, the project works more or less the same way as before, following the ideas of its creators - @Lynx and @Wizballs. Initially it only supported source blocklists in the dnsmasq format, now it supports what we call the 'raw domains' format (sometimes referred to as 'wildcard domains') as well. It never supported the hosts format, so I never had to deal with it. I believe that @dibdot has a broader and deeper view of available formats and their pro's and con's. Which is why I expressed my thoughts as a question rather than as a claim.

Anyway, I'll try to convey in this short post the basics of what I think I know, and perhaps more knowledgeable people will chime in and hopefully confirm or amend this.

Generally, the pre-installed dns resolver on OpenWrt is dnsmasq. This utility has the advantage of small binary, which is obviously beneficial for OpenWrt. It also has an excellent performance. While alternative dns backends are available on OpenWrt, we (developers of adblock-lean) never found a good reason to support them. adblock and adblock-fast, for that matter, support a couple of additional dns backends. Now dnsmasq accepts input formatted in certain ways. For the purpose of adblocking, it is either hosts format or a specially crafted file in its own dnsmasq format.

There is wide range of source blocklists one can get on the Internets. Many of them offer same data in multiple formats, suited to the wide variety of adblockers. Naturally, adblock-lean started off by supporting the native dnsmasq format which could be fed dnsmasq as-is. While working on adblock-lean code, I realized that there are performance and (more importantly) memory benefits in switching to the 'raw domains' format and then converting it into dnsmasq format on the fly. This is why adblock-lean now supports both formats and recommens our users to use the 'raw domains' format where possible.

Now as to the sources of these blocklists. To my understanding, you can broadly divide them into primary sources and secondary sources. Primary sources gather the data in some ways which I don't really have an insight into. I believe most of that is user-reported. The secondary sources combine the output of multiple primary source blocklists, while processing them in a way that should produce an optimal output. This may include deduplication and various forms of compression of the input. adblock-lean doesn't limit the user to any specific sources but it includes presets which are optimized for devices with a certain memory capacity. This achieves both high flexibility and super-simple setup for people who want a good result while spending minimum time. All our default presets are based on a certain selection of Hagezi lists. Hagezi is a secondary source, so his lists are optimized as-is and generally do not require extensive optimization.

adblock supports these lists as well, and many others. This includes the 'steven black' hosts files. The latter (as it seems to me) are not highly optimized, which is why they benefit from TLD compression.

Hope this helped and again - I am not an expert on adblocking, so some things here might be incorrect.

1 Like