Should uclient-fetch work with wolfssl?

Using a snapshot build with imagemaker and wpad-mesh-wolfssl and adblock.
I'm trying to use one crypto library wolfssl rather than openssl (wolfssl is smaller).
Adblock can use uclient-fetch which appears to only be working in ssl download if mbedtls or openssl is loaded.
Should uclient-fetch work (ssl) with wolfssl loaded? If so, is there anything special required to get it to work ie compile from source with some flags set etc?
[edit] libustream-wolfssl and libwolfssl are installed

I'm not sure about wolfSSL, but my experience in building from source is that the TLS library should be among the first things added to the config, so that as other packages get added, they self-select the "desired" TLS library. Otherwise you end up with two or three. Removing libraries isn't automatic, once added, even if the dependency driving them is removed.

For example, something like


before going into make menuconfig

1 Like

I'm not sure where to go with this as I'm using imagebuilder and I thought that the packages were prebuilt (compiled) and all imagbuilder did was download and link those images.

On snapshot, from the command line with the following loaded:


(still with the wolfssl libs installed)
works as expected ie downloads

libuclient and uclient-fetch don't appear to have any dependencies with any ssl package so it may be as you suggest that there is something that needs to be configured in libuclient and/or uclient-fetch that determines if it will use mbedtls or wolfssl.

Funnily enough, this has been bugging me for a few months after building an ADSL router with simple-adblock for a relative while using WolfSSL for wpad/hostapd and hence libustream-wolfssl.

Simply libustream-wolfssl does not work for HTTPS connections and just returns "Connection error: Connection failed" error message. No idea of the cause as I've not got a test system for debugging a running OpenWRT instance.

Looks to have not been working for at least 5 years from forum post wget-error-trying-to-update-he-net which spawned bug 2238 but neither resolved.

The image builder, as far as I know, uses pre-compiled packages, which include their dependencies. I don't know if it has all the variants for different TLS libraries available. You may need to build from source if you want to use different libraries than "standard".

As jeff mentioned, you have more options when building from source, rather than relying on prebuilt binaries. One of the packages probably most involved here is curl/ libcurl, if you build from source, you can choose to build it against mbedtls, openssl or wolfssl (and yes, kconfig will need some encouragement to get the idea) - but binaries are only prebuilt for one of the variants (mbedtls)

1 Like

I think I understand what you and Jeff are saying.
What I'm partially struggling with is that what I think you are both saying is there are packages with (effectively) dependencies when they are compiled but as the 'features' are optional to the base package then the dependency doesn't show up as a load/install requirement.

I'm trying to avoid having to build from source (for no earth shattering reason) and I don't currently have a flash size issue so this is more a learning exercise.
Other packages (wpad, libustream etc) indicate by dependency (and naming) that they require specific packages to work together. uclient-fetch appears to work with both openssl and mbedtls but not wolfssl, is there anyway of determining this from the imagebuilder or is it 'suck it and try'?
Anecdotally (previous comments in the forum) suggest that when wolfssl was called cyassl it did work with uclient-fetch. Mention is also made that uclient-fetch/wolfssl is a viable option in a couple of other threads. I think I hear what you are saying but, I'm suggesting that something may have changed and/or broken over the years.

And (from luci installed software and the command line) I don't have curl/libcurl installed.

It's more that they are "options" of the package and, with so many variations, most of the OSes I work with, OpenWrt, FreeBSD, Debian, ... pick one to package. If you want something different, or a different release version, you have to build it yourself.

You generally can't build a one-size-calls-all version of an executable.

If you look in code, you'll often find things like (made-up example)

#define SOME_FUNCTION(X)    some_openssl_function(X)
#define SOME_FUNCTION(X)    some_mbedtls_function(KEEP_OPEN, X)
#define SOME_FUNCTION(X)    some_wolfssl_function(X, 1)

then, later on, the compiler sees SOME_FUNCTION and substitutes the defined value from the above into

success = SOME_FUNCTION(connection);

so that, at compile time, the proper function from the chosen library is "locked in".

It gets a lot hairier than that, but that's a 10,000-foot view of it.

ok, I've got the mechanics of how you change the compiled code based upon a passed config value.

I've just been searching through the imagebuilder files on my build server and have no hits for any of the SSL packages in a config file. It doesn't look like it's visible there. How would I know what ssl/tls package was used to build the imagebuilder packages? Is it potentially a default in some source code for a package somewhere?

I'd like to find where this configuration/package selection is occurring.

I still think that there is an issue with libustream-wolfssl though.
libustream-openssl and libustream-mbedtls both work with uclient-fetch to download https files. libustream-wolfssl fails when connecting.

Downloading ''
Connecting to
Connection error: Connection failed

The issue may well be that openssl & mbedtls have been integrated into the other relevant packages and wolfssl hasn't. Which is ok, just needs to be noted.

Thought i'd seen a suggestion of using libustream-wolfssl

I build my OpenWRT images from source so it's definitely WolfSSL being used and failing for me. The adblock guides simply suggest libustream-wolfssl as a (what should be working) option as they call the same wget or uclient-fetch regardless of backend used by libustream.

1 Like

It might not work...the user in this thread discovered an issue while attempting to use wolfssl. A wolfssl developer responded:


1 Like

I've tried to reproduce, and it seems that there is indeed something wrong with uclient/ustream-ssl encapsulation layer. I haven't investigated further, perhaps we should check what goes wrong during the connection with ustream-cyassl.
On the other hand, curl seems to work fine with CONFIG_LIBCURL_WOLFSSL on the same build.

I might be able to help if this boils down to a wolfSSL API error.

1 Like

Just to update, I can confirm this has been fixed on git with commit ustream-io-cyassl.c: fix client-mode connections.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.