Hi Gussabina,

If you are using FreeRTOS you can define `FREERTOS` instead of `SINGLE_THREADED` to enable mutex protection in the wolfSSL library.

The wolfMQTT library on the other-hand does not support multi-threads. To solve that you have a couple options:
1. Have one thread dedicated to handling the RX and TX of publish messages. Define `WOLFMQTT_NONBLOCK` and if you get back the `MQTT_CODE_CONTINUE` response code then it means no RX data is available. You can then use/check a FreeRTOS queue for any messages to TX.
2. Use a mutex to protect access to the socket between two threads. You'll also need to use non-blocking mode so you aren't blocked on the socket read.

It sounds like the eventual failure might be due to multiple threads trying to rx/tx publish messages at the same time. This would get the data in the socket out of sync and probably cause the decrypt error.

Thanks,
David Garske, wolfSSL

Hi Csaba,

The wolfCrypt test results up to the point of failure look normal. Typically when we see a failure in RSA its because of a memory or configuration issue.

Please check the following:
1. Make sure your stack enough reserved space. For my wolfCrypt test on a PIC32MZ here I set it to 20480 bytes.
2. If you are setting the FP_MAX_BITS make sure and use the max key size times 2 (so 2048-bit RSA will require `#define FP_MAX_BITS 4096`).
3. For the wolfCrypt self test it requires certificates. Typically these come from the file system in ./certs. If NO_FILESYSTEM is defined then you'll need to set either USE_CERT_BUFFERS_2048 or USE_CERT_BUFFERS_1024 depending on your FP_MAX_BITS.

For setting up the library to just enable SHA1 and RSA you can define `WOLFSSL_USER_SETTINGS` and the `user_settings.h`file somewhere in your include path. You can find examples for this here:

https://github.com/wolfSSL/wolfssl/blob … settings.h

If this doesn't help please let me know the error code from the failed wc_Rsa function and the test which is failing.

Thanks,
David Garske, wolfSSL

Hi kackle123,

Your description of the issue sounds like an MQX networking problem. Perhaps take a step back and setup a simple TCP socket client example to validate your networking functionality would be good.

The wolfSSL library does not handle socket connect or disconnect. With a typical TLS implementation the socket is created and host connected, then `wolfSSL_set_fd()` is called so the wolf IO layer knows the socket descriptor handle to read()/write(). The wolfMQTT library uses the `WOLFSSL_USER_IO` define to enable setting IO callbacks using wolfSSL_SetIORecv() and wolfSSL_SetIOSend(), which handle the read/write inside the wolfMQTT application.

See this code sections for details:
https://github.com/wolfSSL/wolfMQTT/blo … ket.c#L302

The `MqttSocket_Connect()` function first opens the socket using the defined net->connect callback function, then sets up the WOLFSSL object and calls `wolfSSL_connect()`.

If you can send over any logs, code changes or wireshark trace, those will help in understanding the problem.

Thanks,
David Garske, wolfSSL

Hi Kackle123,

If your AWS log shows access denied, then your socket connect() has already occurred and you've entered into the TLS handshake. AWS uses TLS mutual authentication, which requires the device (client) also present a certificate for authentication. Those client certificates are generated by AWS or you can load your own CA and sign them yourself.

See our example here:
https://github.com/wolfSSL/wolfMQTT/blo … iot.c#L193

http://docs.aws.amazon.com/iot/latest/d … ntity.html

To better support this it would be helpful to turn on wolfSSL debugging logs and capture a wireshark trace and send that over. You can email support@wolfssl.com and reference this forum case if you want to keep it confidential.

For logs you need to define `DEBUG_WOLFSSL` and call `wolfSSL_Debugging_ON();` prior to `wolfSSL_Init();`.

Thanks,
David Garske, wolfSSL

Hi Kackle123,

For TLS the socket must be open first then the call to wolfSSL_connect(). If you are having trouble getting past the socket `connect()` that indicates a network level problem. Have you verified you can reach the host? Can you provide some additional information on the platform you are using and how you are building it?

If you are building wolfMQTT for AWS you'll need to make sure TLS support is enabled either using `./configure --enable-tls` or `#define ENABLE_MQTT_TLS`.

Thanks,
David Garske, wolfSSL

Hi Nimesh,

We recently implemented a custom strtok replacement to resolve build environments that do not have an implementation. We found MINGW and a few other build environments are missing this, so we wrote our own.

This change was merged into master on Aug 17, 2017. You can find the pull request here:
https://github.com/wolfSSL/wolfssl/pull/1105

To force use of this define `USE_WOLF_STRTOK`. With configure this would be `./configure CFLAGS="-D USE_WOLF_STRTOK"`.

Let me know if this helps.

Thanks,
David Garske, wolfSSL

Hi Andrey,

My name is David Garske and I'm one of the wolfSSL engineers. I'm working on resolving this issue now. I agree the STM32F2 doesn't support hardware accelerated AES GCM. I'll post an updated with a pull request link shortly.

Thanks,
David Garske, wolfSSL

Hi Nathan,

I assume you have downloaded the Atmel demo `Atmel_ATECC508_Demos.zip` from the web page and are using Atmel Studio to build and debug. Are you using the SAMD21 or some other board?

Would you mind enabling our logging and sending the log output? Add the define `#define DEBUG_WOLFSSL` and call to `wolfSSL_Debugging_ON()` somewhere early in the boot process, like before wolfSSL_init().

A common reason for a fault like that is not setting the stack size high enough.

I created our ATECC508A demo and have the hardware to try and reproduce any issues, so we should be able to resolve this quickly.

Thanks,
David Garske, wolfSSL

Hi embedded,

I recognize the gap in getting return codes from the NetRead back to the caller via the wolfSSL layer. There is a fix I have in mind to pass that through the callback context. I'll push a branch/pull request to GitHub shortly to better demonstrate this. I'll let you know when its available.

Thanks,
David Garske, wolfSSL

Hi n7ekg,

The API for performing a full hash on SHA-256 data is "wc_Sha256Hash". This wraps our internal calls and allows you to provide an input/size and get a hash output (32-bytes for SHA-256).

int wc_Sha256Hash(const byte* data, word32 len, byte* hash);

Also you can call the wolfCrypt API's directly using something like:

#include "wolfssl/wolfcrypt/sha256.h"

Sha256 sha256;
unsigned char hash[SHA256_DIGEST_SIZE];
wc_InitSha256(&sha256);
wc_Sha256Update(&sha256, data, len);
wc_Sha256Final(&sha256, hash);

Of course make sure and check the return code from these, which should be 0 on success.

Here is another example for our wolfCrypt test:
https://github.com/wolfSSL/wolfssl/blob … st.c#L1234

Let me know if that helps.
David Garske, wolfSSL

Hi n7ekg,

You are having a conflict between the min() function and the local variable called min inside integer.c.

I've submitted a patch for this, since min/max as a local variable name isn't ideal.
PR #747: https://github.com/wolfSSL/wolfssl/pull/747

However you could also try defining "WOLFSSSL_HAVE_MIN".
./configure CFLAGS="-DWOLFSSSL_HAVE_MIN"

Thanks, David Garske, wolfSSL