Hello Ashwini,

Could you please confirm that the application is including the same options.h header (or settings.h, if using the user_settings.h method)?

Also please share your configuration and the actual error as printed from the linker.

Thanks,
Eric @ wolfSSL Support

I can't recall if the platform you are using is able to produce debug logs. If so, that could help us determine what is happening when the crash occurs.

Another tool to help determine the stability of wolfSSL is to run the wolfCrypt test application:
https://github.com/wolfSSL/wolfssl/tree … crypt/test

Hi yass007

Certainly it is possible, just not currently implemented. You would need to add functionality for all the operations in order for standardized clients to connect properly. Alternatively, you could integrate a ramdisk that already has filesystem support.

Hello Scotty

The wolfSSL configuration is used to enable / disable support for features (including cipher suites) of the library. In the Win VS build, the configuration is handled by this file:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Are you using a user_settings.h for the embedded system?

When building for embedded devices the best way to configure the wolfSSL library is to create a header named `user_settings.h`. Then at the global level in your application define `WOLFSSL_USER_SETTINGS` (or `./configure --enable-usersettings`) so that when `<wolfssl/wolfcrypt/settings.h>` is included throughout the library the `user_settings.h` header is also pulled in. The application should include `<wolfssl/wolfcrypt/settings.h>`, BEFORE all other wolfSSL headers. A good example `user_settings.h` for getting started on an embedded project can be found in:
https://github.com/wolfSSL/wolfssl/blob … settings.h
That example is well commented and provides a good starting point for any embedded project, even non-ARM based ones!

Hi brunomarcoux

Please send an email to facts@wolfssl.com ands we can help you get started.

Thanks for contacting wolfSSL Support. NIST is currently selecting the next round of post-quantum crypto algorithms:
https://csrc.nist.gov/Projects/post-qua … yptography

The existing NTRU integration will not be maintained. We are aware that the NTRU library we tested with is no longer available:
https://github.com/NTRUOpenSourceProject/ntru-crypto

wolfSSL is working on support for the successor to NTRU:
https://github.com/open-quantum-safe/liboqs

You are welcome to send an email to facts@wolfssl.com to request more information.

Kind regards,
Eric @ wolfSSL Support

Hi sapi01

Need to clarify a couple points from your post:

> When I try to connect to my wolfSSL server, I'm getting `-188` on `wolfSSL_connect()`

Is this error in the client? Both peers will need the self-signed cert. You are basically doing a shared secret when doing mutual authentication and using self-signed certs.

Alternatively you could write a verify callback to override the cert failures for particular servers.

https://github.com/wolfSSL/wolfssl-exam … back.c#L55

Thanks,
Eric @ wolfSSL Support

Hello a940153,

The `SSL_VERIFY_CLIENT_ONCE` flag is regarded as unsafe and is ignored in wolfSSL. You can use session tickets to securely reconnect a peer.

Hi Tammy,

This sounds very similar to the ST HAL issue described here:
https://community.st.com/s/question/0D5 … le-missing

Thanks,
Eric @ wolfSSL Support

Hello kackle123

The web doc is out date from the code. There are two API

int MqttClient_WaitMessage_ex(MqttClient *client, MqttObject* msg,
        int timeout_ms)
{
    return MqttClient_WaitType(client, msg, MQTT_PACKET_TYPE_ANY, 0,
        timeout_ms);
}
int MqttClient_WaitMessage(MqttClient *client, int timeout_ms)
{
    if (client == NULL)
        return MQTT_CODE_ERROR_BAD_ARG;
    return MqttClient_WaitMessage_ex(client, &client->msg, timeout_ms);
}

As you can see, `MqttClient_WaitMessage` does take 2 parameters.

Are you trying to read an incoming publish, whose topic you have already subscribed? You should try setting up a publish callback. Here is an example:
https://github.com/wolfSSL/wolfMQTT/blo … ient.c#L58

Thanks,
Eric @ wolfSSL Support

Hello sahl.john

There is a fix pending for the RNG dependency. This fix will be available in the next release, although I can't provide a specific timeline. I will update as soon as the fix is available (i.e. the PR has been merged).

Thanks,
Eric @ wolfSSL Support