Hi ePaul,

Thanks for the bug report. I was able to reproduce your issue and identiy the cause. I've pushed a wolfSSL fix for this issue here (https://github.com/wolfSSL/wolfssl/pull/1805). It was a new issue that happened after we added some additional fields to support BusinessUnit.

I'm located in PDT (UTC -7).

Thanks,
David Garske, wolfSSL

Hi ePaul,

To build you'll need to use:

Thanks,
David Garske, wolfSSL

Hi AdoraKalb,

That sounds like an issue with not providing enough stack space to the FreeRTOS thread on the xTaskCreate. Try increasing the stack size for that task and let us know if that helps.

Thanks,
David Garske, wolfSSL

Hi kjjy7,

If you are using ./configure you do not need to use user_settings.h. The ./configure outputs a build configuration file to wolfssl/options.h. You can use this file as a template for user_settings.h if you are building the sources directly (without ./configure).

If you are building sources directly then you can define WOLFSSL_USER_SETTINGS and add a user_settings.h file to your include path. There is an excellent template for this here: https://github.com/wolfSSL/wolfssl/blob … settings.h

Thanks,
David Garske, wolfSSL

Hi lupusn00b,

The user_settings.h file is only used when `WOLFSSL_USER_SETTINGS` is defined and is usually used when building the wolfSSL/wolfCrypt sources directly. You asked about only having HMAC+SHA256. It looks like yours is disabling HMAC and SHA256. You should not have the NO_HMAC and NO_SHA256 defined. Also there are a bunch of other defines you'll want for disabling other algorithms.

Here is a good tip: When you run ./configure with your desired options it generates a file in `wolfssl/options.h`. You can use this file as a template for your user_settings.h.

Thanks,
David Garske, wolfSSL

Hi Giovanni,

Have you tried adding `-mlongcalls` to your CFLAGS and CXXFLAGS?

See forum post here:
https://www.esp32.com/viewtopic.php?t=1612

Thanks,
David Garske, wolfSSL

Hi leroyk2,

We have a fix pushed for this here:
https://github.com/wolfSSL/wolfssl/pull/1505

Specifically this line:
https://github.com/wolfSSL/wolfssl/pull … d4937R8575

You may find some of the other improvements in that PR useful as well for the STM32 with CubeMX.

Thanks,
David Garske, wolfSSL

Hi Marco,

The return code from the verify callback allows an error to do overridden. By default the verify callback is only issued in the error case, unless you have `WOLFSSL_ALWAYS_VERIFY_CB` defined. You can use the `store->error` variable to determine the error reason (if one exists). A non-zero return code such a 1 or `WOLFSSL_SUCCESS` allows an error to be overridden. A return value of 0 means continue processing the error in the default way (fail).

For everyones reference the verify callback is set using: `wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_PEER, myVerify);`

Here are some example implementations we use for internal testing of the verify callback:
https://github.com/wolfSSL/wolfssl/blob … st.h#L1361
https://github.com/wolfSSL/wolfssl/blob … st.h#L1404

Thanks,
David Garske, wolfSSL

Hi olle,

We are looking into the DTLS 1.0 report. We see the CLIENT_HELLO retried even though the SERVER_HELLO is received. We believe this causes the DTLS sever to drop the connection since the second CLIENT_HELLO does not include the same packet information as the first request (its missing TLS extensions). We believe this may be a bug with our DTLS 1.0 code and we hope to have a fix available shortly. Thanks for your details report and we will provide you a followup soon.

Thanks,
David Garske, wolfSSL

Hi jebrando,

To resolve this error you have two options:

1. Enable the hardening options `./configure --enable-harden`
2. Disable the hardening support using `./configure CFLAGS="-DWC_NO_HARDEN`

Thanks,
David Garske, wolfSSL

Hi Telina,

AES CBC mode requires the input to be block aligned. Generally the caller will need to add some type of padding to make sure its 16 byte aligned. It would be okay to just pad with zeros. Some people will pad with the pad count value.

AES CTR mode has a feature where the leftover bytes remain in the `Aes` object and are used on the next call.

You do bring up a good point about the wc_AesCbcEncrypt not checking for block size, however the wc_AesCbcDecrypt does. I'll bring this up with the team this week and let you know the reason for this or get a fix for it.

Thanks,
David Garske, wolfSSL

Hi lalonde,

For the RSA using our signature wrapper `wc_SignatureGenerate` the type `WC_SIGNATURE_TYPE_RSA_W_ENC` adds ASN1 DER encoding which includes the OID around the signature. Both `WC_SIGNATURE_TYPE_RSA` and `WC_SIGNATURE_TYPE_RSA_W_ENC` using PKCS v1.5.

Thanks,
David Garske, wolfSSL