Hi mcxbain,

Thanks for contacting wolfSSL Support. This sounds interesting. I will review with the team and post an update. We would welcome your findings if you wanted to go ahead and produce the "wolfSSL amalgamation" and run some benchmarks.

Thanks,
Eric @ wolfSSL Support

Are you using Cygwin?

Hi Jeremy,

Thanks for submitting this on Zendesk. I will copy the answer here also to help other users.

Here is a very straight forward RSA signing example:
https://github.com/wolfSSL/wolfssl-exam … pk/rsa-pss

And for the TLS examples, you can always use the client and server that come packaged in the main library:
https://github.com/wolfSSL/wolfssl/tree … les/client
https://github.com/wolfSSL/wolfssl/tree … les/server

The client can print the available ciphers using the option -e

./examples/client/client -e
wolfSSL Entering wolfSSL_Init
wolfSSL Entering wolfCrypt_Init
TLS13-AES128-GCM-SHA256:TLS13-AES256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305-OLD:ECDHE-ECDSA-CHACHA20-POLY1305-OLD:DHE-RSA-CHACHA20-POLY1305-OLD

You can specify a particular cipher suite using the option -l

./examples/client/client -l ECDHE-RSA-AES128-GCM-SHA256

For a simpler TLS example you can review:
https://github.com/wolfSSL/wolfssl-exam … ls-ecdhe.c

What errors did you see when trying to install the wolfssl-py library?

Enabling the ciphers in wolfSSL will not enable them openSSL, so you'll need to be using wolfSSL for us to help.

Hello Iyaps,

Welcome to the wolfSSL Support forum. Have you already downloaded (or cloned from Github) the wolfSSL project? There are several Xilinx SDK examples here:
https://github.com/wolfSSL/wolfssl/tree … /XilinxSDK

> 1. I would like to communicate with external devices with or without SSL/TLS security. So Is it possible to communicate without using SSL/TLS security with wolfSSL API's?

Usually your application will determine if TLS is required (i.e., "http://www.example.com" VS "https://www.example.com"). The same application code will be used, but the TLS connection should only be used when connecting to servers / clients that support it.

2. I know that wolfSSL is the successor of CyaSSL. But I would like to know what is the base layer of wolfSSL/yaSSL is developed from. Whether wolfSSL uses openSSL or LwIP functions internally?

wolfSSL is written from scratch and maintained by the wolfSSL team! That is one reason developers prefer wolfSSL over so many other SSL and crypto libraries.

Kind regards,
Eric @ wolfSSL Support

Hi @agubisch

No, I think you are correct. It looks like MqttClient_Publish_WritePayload has overloaded the meaning of the return value MQTT_CODE_CONTINUE, so that the publish callback does not work correctly when non-blocking is enabled. I think a new return code is needed to specify the condition that the callback should be executed again.

I opened a ticket to track this defect
https://github.com/wolfSSL/wolfMQTT/issues/192

Thanks for your help investigating this issue!

-Eric @ wolfSSL Support

The socket is closed (in the example code) by mqttexample.c::NetDisconnect, which is called from mqtt_socket.c::MqttSocket_Disconnect
https://github.com/wolfSSL/wolfMQTT/blo … ket.c#L480

There are not a lot of mallocs in the library proper, so it should be possible to use a memcheck tool to find the culprit. We sometimes use valgrind to hunt for mem leaks.

Hello @agubisch

It looks like there was a fix added to properly return the MQTT_CODE_CONTINUE error. Could you please confirm the release? Also can you please confirm that WOLFMQTT_NONBLOCK is defined in the settings?

Thanks,
Eric @ wolfSSL Support

Hello Anthony,

The callback description is here:
https://github.com/wolfSSL/wolfMQTT/blo … ient.h#L49

The callback is registered during `MqttClient_Init`, and it will be called when a published message is received on a topic the client is subscribed to. The topic name and total payload size are available in the `MqttMessage` parameter. The msg_new and msg_done parameters are used to indicate the progress of the payload.

There is an excellent example that demonstrates receiving a large payload using the message callback functionality. It a two part example, the first client creates and publishes a signed "firmware" blob. The second client is subscribed to the topic waiting for the firmware message. When it receives the message, it saves the payload and authenticates the firmware package.

https://github.com/wolfSSL/wolfMQTT/tre … s/firmware

Instructions:
https://github.com/wolfSSL/wolfMQTT/blo … re-example

Thanks,
Eric @ wolfSSL Support

Hi JasP

We support all users of wolfSSL libraries! You can open a support ticket by emailing support@wolfssl.com anytime.

It looks like this is a good example of connecting an MQTT client to the ThingSpeak broker:
https://www.mathworks.com/help/thingspe … p8266.html

From there we know the broker is "mqtt.thingspeak.com"; clientID is random; the username and password will come from your ThingSpeak account settings.

It does not appear to use a secure connection, so TLS can be disabled in the wolfMQTT configuration. This is likely the source of the MqttNet callback error you saw.

Are you building for an embedded platform? Have you tried running our existing examples?

Thanks,
Eric @ wolfSSL Support

Edit:
Here is an even better discussion of using an MQTT client with ThingSpeak:
https://www.mathworks.com/help/thingspe … asics.html

Hello Gil,

Thank you for contacting wolfSSL Support. Is your application based on the wolfMQTT example from Microchip? Have you reviewed the latest version from the Harmony 3 Content Manager?

It looks like there were a number of changes to address initialization (and uninit) using the "Net_Glue" component.

Without having seen the whole execution loop, I can't say for sure. In the snippet you provided I don't see in where the state is being reset.

Thanks,
Eric @ wolfSSL Support

EDIT: I see the state reset, now. But without seeing the rest of the application loop I don't know if it is being reinitialized.