Wpad-mesh-wolfssl or wpad-mesh-openssl

Good morning / evening, since version 21.02 and Master several wolfSSL dependencies are included by default, example:

  • libwolfssl
  • libustream-wolfssl
  • wpad-basic-wolfssl

I was wondering which of these dependencies would give me better mesh stability and why?:

  • wpad-mesh-wolfssl
  • wpad-mesh-openssl

I hope your help.

Hi.
I'm using wolfssl in a mesh network without any issue. Openssl should be considered as much reliable. The only real difference is that wolfssl is lighter in memory, and I assume that is why it has been chosen by the dev team as default.

1 Like

It depends if you use other packages with dependency OpenSSL or WolfSSL. If you only use basic LuCI, use WolfSSL.

1 Like

Agreed.
I'm also also using openssl as a dependency of openvpn.

1 Like

So use OpenSSL. Likewise, the OpenSSL library was recently changed to WolfSSL in OpenVPN.

1 Like

Oh ? interesting. That will allow me to drop any openssl dependecy.
I'm aware of this thread

but is seems that the rsa tool are not available. I must confess that I have not had a look to the matter for a long time.

1 Like

I think so. At least if you mean the openvpn-easy-rsa package

1 Like

yes.
I have just browsed the packages directory and found
openvpn-openssl_2.5.3-2_x86_64.ipk
but still not find some kind of openvpn-wolffsll.ipk

1 Like

To be perfectly honest, I'll drop openvpn (openssl or wolfssl) as
soon as I'll understand how to configure wireguard in an efficient way. :crazy_face:

2 Likes

Because the package is in master. It was added recently. Besides, when wanting to install openvpn-easy-rsa, I see that you need OpenSSL, so you are right that this tool is not yet compatible with WolfSSL.

1 Like

openvpn-wolfssl is available only to devices running development snapshot.
Not even devices on release 21.02-rc have it.

In the future it will be in releases too

1 Like

I installed Mesh on two Archer C7 (one v2 the other v5).

wolfssl was not a problem.

I had to replace ath10k-firmware-qca988x-ct for the non-Candela version ath10k-firmware-qca988x to make mesh work.

I used 801.11s because it is implemented by default and does not require any additional software packages.

No tutorial I found described the procedure correctly. Openwrt documentation is not up to 21.02 either.

1 Like

ok, good to read. It's just a matter of time. thanks.

1 Like

Watch this. You may find some clues.

1 Like

Openssl should be considered as much reliable.

I misspoke what I meant : both openssl and wolfsll should be considered equaly reliable.

1 Like

I see that you have found the right sources :wink:

2 Likes

Well, you can give users a return of experience by editing those guides.

1 Like

@badulesia:

I think it is a misconception that users should write documentation.

They don't have the knowledge (that's why they refer to documentation), the technical means (only single devices usually) or the time to research to write comprehensive docs.

It is the developer that has all knowledge about the code and (hopefully) sufficient technical equipment to test the procedures.

Users choose solutions based on technical versatility, stability and available help to implement them.

If the documentation (at the time of writing v 21.02-rc3 is out) still covers LEDE 17.x there is something seriously flawed.

If there are how-tos out there that suggest installing batman while simple correcting the firmware and using standard functionality would suffice there is something seriously flawed.

As for me: I cannot recompile openwrt to use openssl and I cannot create binaries to correct the firmware. I do expect this from the developers of Openwrt or have to revert to the factory image of my router.

On a final note: openssl was default in 19.07. It was replaced on 21.02 and broke a lot of scripts. If these types of decision are taken so lightheartedly Openwrt will end like most open source projects.

2 Likes

$50 and hour x 5000 hours to update the whole wiki... =

$250 000

would you like to make a donation?

seriously... I could never do what the developers do... and they really don't generally have time to devote unpaid energy to documenting stuff...

so now and then... I try to contribute... more contributors = more/better docs... cost =

$0

( I think if you reflect on the point you've made... the majority of causation is due to pace of change... which can be a double edged sword for which clear 'deliverables' derived from communal efforts will always be a challenge )

archaic != unproductive
usability != functionality

everything in life is a double edge sword... set achievables and organization styfle creativity...