Some more tests at my end, I manually downgraded to v0.8.
While we’ve already established that notifications like “The locally installed adblock-lean is the latest version." are no longer available in logs (for v0.8 and later), which is okay if no updates are actually available, I wanted to check if v0.8 at-least notifies if an update is actually available through messages like“The locally installed adblock-lean seems to be outdated...", looks like this isn’t happening either:
@antonk sir just out of curiosity, can you share link for xxx.txt of hagezi-mini you're using in adblock-lean as it's pretty efficient
I see many mini links on hagezi GitHub page so confused
I think syslog is intended for important events concerning the system. I find it hard to classify an update available for an application as such. Also I can't think of one other example of an application advertising its updates in the syslog.
Thanks for getting back, I think most messages around adblock-lean’s operations are already logged, just restoring the update notification would be great.
About this - most apps are managed by opkg, so seeing updates for them in the software tab is expected. Since we’re operating outside of that system, I think syslog makes a lot of sense :).
With adblock-lean v0.8 we dramatically reduced the number of messages sent to the syslog, so now only the absolute minimum is sent.
I was referring not just to OpenWrt and even not just to Linux. I can't recall a single example of an application advertising its updates via the system log, be it on Linux, Windows or MacOS (and I have looked at logs of all three platforms, a lot). Probably if you look really hard, you can find an example, but that would be a rare exception to the rule.
Anyway, I'm reworking the code related to writing logs in adblock-lean, so hopefully with the next release we will have a config option to set the desired log level and this way everybody will be happy.
I installed Adblock-lean on my router (openwrt-24.10 branch) and can not make it work. I guess Wireguard I am using can be the case. Is there anyone has the same setup to give me a tip what I can be missing here?
Thanks
I’ve been using this great script for a few days now, having previously been a PiHole user. But…
I cannot find how to view what ip’s have been blocked?
I’ve got a couple of streaming services (5UK in particular) which won’t load while adblock-lean is running so I need to find what ip to whitelist. Easy to do on PiHole, but I can’t see how to do it here (probably being blind so apologies upfront!)
I can see a switch (ABL_DEBUG_LOG) in the code, but it is never set. Do I need to set this?
Similar to how every other adblocker for OpenWrt works, adblock-lean does not process DNS requests on its own, it relies on the system DNS resolver to perform the actual blocking. adblock-lean specifically works with dnsmasq resolver which is the default resolver on OpenWrt. For this reason, only dnsmasq knows which requests have been blocked, hence I don't know any better method to get a list of blocked requests than what @reinerotto suggested (i.e. configuring dnsmasq to log such blocked requests). In theory, we could integrate some automation for this procedure as part of adblock-lean but I'm not sure this would provide any value over setting this option directly in /etc/config/dhcp. In addition to that, we could perhaps set a dedicated log file for these events and print it out on demand. But I don't think it's worth to do unless additional users are interested in this functionality.
This has to do with which adblock-lean's own progress messages are sent to system log. This type of logging is being reworked and the next version will have user-configurable log levels.
Hi all, I'd like to discuss a new feature which has been asked for several times - the option to have the blocklist stored permanently and possibly that the permanently stored copy would be loaded at boot.
This feature required a lot of code changes. At this point, I have implemented most of it. Now it's down to some specifics which I have some doubts about and I'm interested to hear your input.
Our initial plan was to introduce two new config options: PERM_BLOCKLIST_DIR and PERM_BLOCKLIST_IS_MAIN.
When the former option is set, when running at boot, adblock-lean would look for a pre-processed copy of the blocklist in the specified directory and if found, load it immediately (before the boot start delay), then wait the boot start delay time and then download and process updated blocklist as usual, and load it into dnsmasq. The benefit is that adblocking would be available sooner after boot. Unless the latter option is set, that blocklist copy would not be created or updated automatically, so it would be up to the user to create and maintain the blocklist copy in that permanent location.
When both the former and the latter options are set, adblock-lean would do the same as above, but also automatically update the permanent blocklist and never create a copy of the blocklist on the ramdisk, this way also saving some RAM. The reason to have this as a separate option is that some users may want or need to use the built-in router flash for storing the permanent copy, and updating that copy automatically on a daily basis would seriously accelerate flash wear.
Now my doubts are related to loading the blocklist twice at boot - once the permanently stored blocklist and second time the newly downloaded and processed blocklist. Each time this process interrupts DNS resolution and DHCP services until it's done, and it takes some time to complete, especially so on low-end devices. So if we go ahead with the planned implementation, there would be two such interruptions, rather than one. I feel that this is not a great idea. So I'm thinking what would be a more sensible way to implement this and I'm looking for community input on this matter. @SeriousHoax including you, as you were one of the people who requested this feature.
Only thinking out loud but how about leveraging concurrent instances and then instant switchover? Or, alternatively, whilst dnsmasq is down, simply direct all queries to resolver (but this should’ve optional since it would bypass blocking).
I like the creative thinking. Unfortunately, I don't think "instant switchover" is technically possible. And even if it is, spinning up and destroying dnsmasq instances on-demand seems like a bit too much, complexity-wise.
I have an old cheap tp-link router, forgot the model but around 5/6 years old now I think, that’s one of those with only 2.4GHz and only 64MB RAM that I remember setting basic/default openwrt with stubby and adblock-lean setup and forget afterwards used in my parent’s place. I don’t have that router set to reboot at any given time, it even has one of those powerbank-like backup power for the router in case of power outage that rarely happen anyway over there unless due to heavy thunderstorms or a power line is cut and the likes. If I remember correctly, I even have the cronjob to be something like between 8-14 of the month that is on a Friday late night to update the blocklist and last update I did was to include a manual scheduled task to run the update -y param between 22-29 of the month that is on a Friday late night when that was added (can’t remember if I updated it to 24.10 as well, it’s been a while).
With this new feature, it’s indeed a good benefit to have adblocking running sooner after boot. From my understanding, if possible, add an enable tag/option for it first, then another check to see if the dir is set otherwise enable is ignored and then if set to enable and with a valid dir to skip the initial startup blocklist update, so a blocklist update would only then happen at the cronjob schedule. Then maybe have a way to set a command specifically just to update the defined permanent file. That way I can just manually add a scheduled task to run that command to update the permanent file. Having an enable option allow me to just set the feature to disable too without manually removing the dir value later on whenever I don’t want to use the feature anymore.
EDIT: For my main router, a Linksys EA8300, I can then utilize the USB port in case I’ll use this feature as well.
I reckon it would be by establishing concurrent instance (supported in recent OpenWrt versions) and flipping between dnsmasq instances for incoming DNS requests.
I understand it would add some more complexity and it's an odd one because it'd require at least temporarily some more RAM to work, with the benefit of reduced downtime.
More thoughts out loud, but the dnsmasq options are pretty extensive, and these look rather interesting:
--connmark-allowlist-enable[=]
Enables filtering of incoming DNS queries with associated Linux connection track marks according to individual allowlists configured via a series of --connmark-allowlist options. Disallowed queries are not forwarded; they are rejected with a REFUSED error code. DNS queries are only allowed if they do not have an associated Linux connection track mark, or if the queried domains match the configured DNS patterns for the associated Linux connection track mark. If no allowlist is configured for a Linux connection track mark, all DNS queries associated with that mark are rejected. If a mask is specified, Linux connection track marks are first bitwise ANDed with the given mask before being processed. --connmark-allowlist=[/][,[/...]]
Configures the DNS patterns that are allowed in DNS queries associated with the given Linux connection track mark. If a mask is specified, Linux connection track marks are first bitwise ANDed with the given mask before they are compared to the given connection track mark. Patterns follow the syntax of DNS names, but additionally allow the wildcard character "" to be used up to twice per label to match 0 or more characters within that label. Note that the wildcard never matches a dot (e.g., ".example.com" matches "api.example.com" but not "api.us.example.com"). Patterns must be fully qualified, i.e., consist of at least two labels. The final label must not be fully numeric, and must not be the "local" pseudo-TLD. A pattern must end with at least two literal (non-wildcard) labels. Instead of a pattern, "*" can be specified to disable allowlist filtering for a given Linux connection track mark entirely.
Makes me wonder whether nftables could be leveraged in ways we haven't thought before. For example, seems one could use the marks to enable a two-tier blocklist (e.g. parent or child devices). I wonder even whether we could alter marks based on content of request using nftables.
