Missing Unbound package on OpenWrt 19.07

I have checked the techdata page of my router and fount that the Package architecture is arm_cortex-a9_vfpv3.

Checking the packages page there is no Unbound package.

Is this because the package was not build yet by the buildbot?

Hi,

I had the same problem and ended with installing unbound-daemon package instead of unbound.

Unfortunately I cannot get it up. It ends in a crash loop with default config.

Best regards
Robert

According to:
https://buildbot.openwrt.org/openwrt-19.07/packages/waterfall
all packages are built for this package architecture.

And according to:
https://downloads.openwrt.org/releases/faillogs-19.07/
there is also no log about a error for unbound.

What about the following packages?

I have tried following the DNS over TLS with Unbound guide, and they use the unbound package in the install instructions:
opkg install unbound ca-bundle

I have also checked the packages for 18.06.6, and package page contains unbound_1.9.6-1_arm_cortex-a9_vfpv3.ipk

Fresh instalation after back to stock TP-Link TL-WDR3500 v1
Firmware Version

OpenWrt 19.07.0 r10860-a3ffeb413b / LuCI openwrt-19.07 branch git-20.006.26738-35aa527

Everything working fast except unbound. I am install ALL packages following the guide https://github.com/openwrt/packages/tree/openwrt-19.07/net/unbound/files/README.md
but dns is dead.

Check logread for pointers and try launching unbound manually. Check if the port unbound wants to bind to is not claimed already (with netstat e.g.). 'It's not working' could mean your house is on fire as well.

Perhaps name changed, have you installed unbound-deamon?

I have tried the unbound-daemon package, but I have the same issue as imk82. It ends up in a crash loop.

Using unbound-daemon-heavy works on WDR3600 ath79.
Previously, trying to use unbound-daemon always resulted in crash loop.

@davids @imk82 Could you test unbound-daemon like @geofb did? So running unbound -c /etc/unbound/unbound.conf and see if these errors pop up:

Error relocating /usr/sbin/unbound: ub_thr_fork_create: symbol not found
Error relocating /usr/sbin/unbound: ub_thr_fork_wait: symbol not found

Someone needs to file a bug report then so this can be fixed for 19.07.1.

This can also be fixed for 19.07.0 as this package isn't included by default in the images.

Push fix to 19.07 packages repo, wait for build by buildbot and do opkg upgrade unbound-daemon.

1 Like

Possibly also @EricLuehrsen could help in diagnosing the crashing unbound instances in 19.07.

1 Like

Judging by the error messages something in the conditional compile changed in Unbound 1.9.6. Without libpthread Unbound will need to use the basic fork method. One of its internal handlers is not compiling in. The install size, complexity, and load of thread management is why there are two variants. As long as your router has space, use unbound-daemon-heavy until I can figure this out.

Also in make menuconfig make sure libunbound is selected that matches. If the threaded libunbound is mixed with the forked Unbound, then Unbound will not find the fork handlers in libunbound. There may be an autoselect issue.

4 Likes

Using unbound-daemon and running the command specified by @Borromini produced the same errors:
unbound_error

Changing to unbound-daemon-heavy seems to work

Also had troubles with unbound-daemon package.
So i switched to unbound-daemon-heavy package and its working.

While installation it mentioned that unbound-daemon-heavy is for large networks so i'm wondering if its also suitable for small networks ? Any downsides using it in small (<= 10 devices) network enviroment ?

I'm running DNS over TLS on a ar71xx device.

The heavy network traffic variant uses libpthreadand libevent with their library dependencies to permit multi threading within Unbound and permit opening substantial ports. However on the traditional favorite ath79 (ar71xx) targets, you have one core and limited flash. Light variant can save 20% CPU load and significant ROM. It is why it is default because it has the highest chance of fitting. The locking handles on each cache event are skipped. It won't use extra ROM for Unbound and libraries. For ARM and x86 targets, its no big deal. Even if you don't think you will see heavy traffic, then you might as well install it. Multi threading for 2 threads on multi core CPU but with 1 cache can really help with TLS response, while not generating cache misses. Remember to set the multi threading UCI if you do have multi core.

See libevent and fork operation notes

2 Likes

I can also confirm that it works without problems while using the unbound-daemon-heavy package. With the other one I also see the following errors when starting unbound from the command line:

Error relocating /usr/sbin/unbound: ub_thr_fork_create: symbol not found
Error relocating /usr/sbin/unbound: ub_thr_fork_wait: symbol not found

Best regards
Robert

I think this might be a problem for the package installer, but not build from source. When built from source, a Makefile symbol marks the default package and the correct libunbound is autoselected with unbound. If you install packages from your router opkg, then it may cross. You may get the heavy libunbound with light weight Unbound. Try it in two steps. Install libunbound first and unbound-daemon second. I am not sure how to control default variants for opkg. I will need to look at that.

1 Like

it seem you are right:

root@OpenWrt-19:~# opkg info unbound-daemon
Package: unbound-daemon
Version: 1.9.6-2
Depends: libc, libopenssl1.1, libunbound
Status: install user installed
Section: net
Architecture: x86_64
Size: 121253

root@OpenWrt-19:~# opkg info libunbound-heavy
Package: libunbound-heavy
Version: 1.9.6-2
Depends: libc, libopenssl1.1, libpthread, libevent2-7, libevent2-pthreads7
Provides: libunbound
Status: unknown ok not-installed
Section: libs
Architecture: x86_64
Size: 391530

Installing libunbound first and then unbound-daemon solve the issue
:slight_smile:

Sounds like a dependency definition problem.

I would expect that unbound-daemon-heavy depends on libunbound-heavy, and unbound-daemon on libunbound-light (or something) if there really is a corresponding difference in libraries. Looking at the Makefile shows that it is not so.

My two cents:

change the Makefile so that

  • define both libunbound-heavy and libunbound-light that both PROVIDE libunbound
  • make unbound-heavy and unbound-light to depend directly on the corresponding libunbound-heavy and libunbound-light
  • other end-user modules depend on libunbound

Would that work?