Adblock package release for turris omnia


Hey @didbot,

It was always troubled me that /etc/init.d/adblock status gives no response if'0' (as below - the boldness is my highlight):

root@sr-router:~# /etc/init.d/adblock status
::: adblock runtime information

  • adblock_status : enabled
  • adblock_version : 3.4.0
  • overall_domains : 19024 (normal mode)
  • fetch_utility : wget (built-in)
  • dns_backend : kresd (/etc/kresd)
  • last_rundate : 05.01.2018 18:18:07
  • system_release : Turris Omnia, OpenWrt omnia 15.05/3.9.1
    root@sr-router:~# uci set'0’
    root@sr-router:~# /etc/init.d/adblock status
    root@sr-router:~# uci set'1’
    root@sr-router:~# /etc/init.d/adblock status
    ::: adblock runtime information
  • adblock_status : disabled
  • adblock_version : 3.4.0
  • overall_domains : 0 (normal mode)
  • fetch_utility :
  • dns_backend : kresd (/etc/kresd)
  • last_rundate : 05.01.2018 18:22:34
  • system_release : Turris Omnia, OpenWrt omnia 15.05/3.9.1

I have seen many people (including myself) get stuck because this behaviour is a little counter-intuitive (you ask a question, and get no response). I accept the adblock service itself may be disabled, but the init.d wrapper is enabled/disabled by a different means (i.e. in rc.d), and certainly not by the configuration files in \etc\config.

I know there is a log entry (adblock is currently disabled, please set adb_enabled to '1' to use this service), but couldn’t there be a console message (and for too)?

For that matter, what exactly does adblock_status : disabled mean? Doesn’t it actually mean inactive? Or is the behaviour above caused by the bug you’ve fixed in 3.4.1 - my system is now stuck on start adblock processing (reload)?


This is commonly used by so called community builders/builds, which add the adblock package though disabled by default. If you would like to disable adblock temporary, use the suspend/resume functionality.

In adblock 3.4.1 I’ve fixed the status handling, even the ‘disabled’ state will be printed correctly. In the previous adblock release there was a ‘status’ race condition whenever the adblock process was running in parallel.

Adblock 3.4.1 is now in trunk and the ready to run packages will be available probably tomorrow.


For the record IMHO " /etc/init.d/adblock status" should always say something. Silence is simply disconcerting and suggests something is broken. Sort of like asking someone what time it is and getting a blank stare for a reply ;-).


I agree completely!!!


Sounds reasonable. It’s already implemented in the LuCI-frontend of current adblock 3.4.1 - the missing command line output will be added in forthcoming adblock 3.4.2.


Have another question. I installed adblock 3.4.0 at the end of last year and recently I upgraded to 3.4.1. Everything works fine, the configuration is consistent, services work, but the Omnia rolled back to 3.4.0 one day later. in the Localrepo both versions are in it, is that the reason? where can I prevent it from rolling back?



there is an excellent description of this new localrepo feature, see here


Hi @dibdot,

I just upgraded to v3.4.3, and have the following for you:

2018-01-13T17:50:39+00:00 debug adblock-[3.4.3]: f_main ::: name: adaway, enabled: 1
2018-01-13T17:50:39+00:00 debug adblock-[3.4.3]: f_main ::: url:, rc: 1, src_log: /usr/bin/uclient-fetch: unrecognized option: timeout=10

…and, FYI:

root@sr-router:/tmp# /usr/bin/uclient-fetch
Usage: /usr/bin/uclient-fetch [options]
-q: Turn off status messages
-O : Redirect output to file (use “-” for stdout)

HTTPS options:
–ca-certificate=: Load CA certificates from file
–no-check-certificate: don’t validate the server’s certificate

Switching to wget solves the problem, and behaviour returns to normal.



If anyone is interested, this is how I install / upgrade adblock on my Turris Omnia:

opkg remove adblock --force-removal-of-dependent-packages

cd /tmp
wget -N${VER_ADB}_all.ipk
wget -N${VER_GIT}_all.ipk

opkg install adblock_${VER_ADB}_all.ipk --force-maintainer
opkg install luci-app-adblock_git-${VER_GIT}_all.ipk

cat > /etc/adblock/adblock.whitelist << EOF

uci set adblock.disconnect.enabled='0’
uci set adblock.hphosts.enabled=‘1’

for IDX in cn de id nl pl ro ru; do
uci del adblock.reg_${IDX}

uci set'kresd’
uci set'wget’
uci set'timed’
uci set'1’
uci commit

/etc/init.d/adblock enable
/etc/init.d/adblock start

Network-level ad blocking

That’s expected, cause Turris Omnia base is still on Chaos Calmer release level and the included uclient-fetch version is very rudimental.

Edit: I’ve provided a pre-configured/optimized adblock.conf for further adblock package integration (see here)


Yes - I see your changes are 100% as per my section.

For those who are not sure why @didbot is using a .conf file and I am using uci command - they are two different ways of achieving the same thing. The UCI is is a core part of OpenWrt/LEDE and is one way of making changes to the configuration files in /etc/config (another is to edit the files directly).

I like to use uci command simple because they scriptable.

When the Omnia’s official package repository eventually contains a recent-enough version of adblock, it will include the appropriate version of adblock.conf.


Thank you for your answer! I have created the default localrepo, following this example here:

Everything was created and I made the entry in the user.lua.
But made the mistake and deleted from the localrepo-auto the previous versions, for whatever reason.

What surprised me too, why I get a message by mail the updater has an unknown error?

Did he want to roll back to 3.4.0 and could not it because the packages no longer exist in localrepo-auto?
How can I get the localrepo-auto up-to-date?
localrepo list gives me this output:

/ $ localrepo list
adblock: 3.4.1-1 3.4.3-1 3.4.0-1
luci-app-adblock: git-17.362.62617-4f644d9-1
adblock: 3.4.3-1

Since the Updater does not have the previous two versions in localrepo-auto, how can I remove them from the list?
About which entry or which file I can clear this list, it all works well on version 3.4.3-1

Best regards


Installation of 3.4.3-1 failed for me - for some reason it doesn’t start:


Probably the service has been disabled. Try

/etc/init.d/adblock enable (or in LuCI under System => Startup)


Sorry I have no idea, maybe it’s better to ask in the above linked “localrepo thread”.

usage: localrepo [-h] [--path PATH] {list,add,rm,get,clean,check} ...

Local opkg repository management script.

optional arguments:
  -h, --help            show this help message and exit
  --path PATH           Path to repository (usable if we are working out of
                        root). In default path /usr/share/updater/localrepo is

    list                List all packages in repository
    add                 Add packages to repository
    rm                  Add packages to repository
    get                 Copy package from repository to current working
    clean               Clean unused packages (not installed ones) from
    check               Check repository index and related files and
                        optionally fix inconsistencies.

Did you try the check command? That would be my first guess. Maybe rm could work - not sure how the checks for actual files are configured there…

Just noticed typo in rm command description. Maybe @cynerd already knows about it…


Well I don’t. Thank you for reporting it. It’s kind of funny typo.

Anyway I accept that it is not documented but you have to use underscore to specify version (it’s same format as package naming uses). So for example something like this localrepo rm --repo auto adblock_3.4.1-1. Also if you specify it without version it should remove all packages of that version from given repository. Also note that if you don’t specify repository that you are working just with user repository.

As last thing just small note. There is known bug with this syntax and because of that it’s subject to change. Reference:


Thanks, everything works! Had exactly the same mistake in the localrepo as @dibdot. Based on both threads


I cleaned up the localrepo and fixed the error with the Updater!
Thanks also to @Jirka and @cynerd.
Very understandable explanation.

Best regards


Of course you were right, thank you!


kindly supported by @cynerd I could update the initial post with the latest adblock updates, please also note the “limitations” section.