Hi kjjy7,

Try using the function `wolfSSL_get_state`. We also have an API `wolfSSL_state_string_long` which gets a string version of the current state.

We also have an internal TLS client state is in `ssl->options.clientState`. The possible values are here: https://github.com/wolfSSL/wolfssl/blob … al.h#L1428

Let us know if that is helpful or not.

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

328

(1 replies, posted in wolfSSL)

Hi Te,

Fix posted here: https://github.com/wolfSSL/wolfssl/pull/1689

Thanks.
David Garske, wolfSSL

329

(1 replies, posted in wolfMQTT)

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

330

(3 replies, posted in wolfSSL)

Hi Gil,

Yes you can disable DH if you are using ECC or a static cipher suite.

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

332

(1 replies, posted in wolfMQTT)

Hi Ed,

Thanks for the report of these issues. I've fixed the script for directory check. The double equal works on some platforms, but you are right the single equal is the best practice. Fix pushed here: https://github.com/wolfSSL/wolfMQTT/com … o?expand=1

Is the `~/ARDUINO`a standard location on all platforms? The example we built uses the `#include <wolfMQTT.h>` include. Where did you see the `wolfmqtt.h` case expected?

Thanks,
David Garske, wolfSSL

333

(1 replies, posted in 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 PeterL,

Thanks so much for the excellent bug report!

I've issued a fix for this here:
https://github.com/wolfSSL/wolfMQTT/pull/52

We should be doing a wolfMQTT release by the end of the month. This change will be included.

We are always curious how customers are using wolfMQTT and wolfSSL, so it would be great to hear from you by email at info@wolfssl.com.

Please feel free to ask additional questions anytime. You can also get support using support@wolfssl.com.

Thanks,
David Garske, wolfSSL

335

(25 replies, posted in 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

336

(25 replies, posted in wolfSSL)

Hi olle,

The alert 40 is `handshake_failure`. That might indicate a PSK key error. What are you using for the server side? We'd like to setup a local test against the same DTLS server.

Have you seen our example PSK callback functions here?
https://github.com/wolfSSL/wolfssl/blob … st.h#L1082

Thanks,
David Garske, wolfSSL

337

(3 replies, posted in 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 zoomto.jitendra,

The net_pres_enc_glue.c is a generated file from the Harmony tool. Under the networking section you will find a net presentation checkbox.

The wolfmqtt_client example demonstrates your basic MQTT client features such as connect, subscribe and publish. The `wolfmqtt_firmware` project demonstrates using MQTT for a firmware update example.

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 smitthhyy,

I am the author of the wolfMQTT library and did the integration into Harmony. I just downloaded the Harmony v2.05 to test it out. You must be having some include issues. The build error doesn't make sense to me since `mqtt_packet.h`defines `MqttMessage`, which is included just above in mqtt_client.h.

As for v0.10 in Harmony it looks like Microchip hasn't been updating the library, so I will ping them about getting it updated.

For now the best solution is to download the latest from us directly and replace it inside the Harmony `third_party/tcpip/wolfmqtt`.
https://github.com/wolfSSL/wolfMQTT
Then you'll have to re-generate your Harmony code. The README.md Kaleb provided explains how to do this.

Let me know if that is helpful or not. If you continue to get errors please email us at support@wolfssl.com and include the project for reference.

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

342

(1 replies, posted in wolfCrypt)

Hi ravi.kumar,

To use the `TLS13-AES128-GCM-SHA256` cipher suite you must also enable AES GCM. Please try adding `--enable-aesgcm` to your ./configure options.

Another helpful tip is you can get a list of available cipher suites using:
./examples/client/client -e

You can get a list of ./configure commands using `./configure --help`.

Thanks,
David Garske, wolfSSL

Hi swessidorsaf,

Have you downloaded the latest v3.12.2 release we just posted?
https://github.com/wolfSSL/wolfssl/rele … 2.2-stable

If you are getting a "make check" error can you provide the ./configure string you are using the the platform/OS?

Thanks,
David Garske, wolfSSL

Hi Cxdinter,

Most AES mode require the input to be multiples of block size (16 bytes). TLS handles padding for block size. You should be able to pad with zeros if you want as long as the input is a multiple of 16 bytes. The resulting output will be the same length as the input. The decrypted text on the other side will have the padding and be a multiple of the block size. Most padding scheme use a length and known pad character. If you want to use AES and not worry about padding, I'd recommend AES GCM, which is an authentication cipher (wc_AesGcmEncrypt / wc_AesGcmDecrypt) and allows for any size input.

Thanks,
David Garske, wolfSSL

Hi cxdinter,

RSA can encrypt up to the key size (2048 bits is 256 bytes), but it is not something you would normally use to encrypt larger amounts of data because of performance. Typically a key is secretly exchanged using DHE or ECDHE and that key is used as an encryption key for AES, 3DES or ChaCha20. This is what TLS handles automatically. Can you provide some more background to help us understand the situation?

The RSA functions are wc_RsaPublicEncrypt and wc_RsaPrivateDecrypt.
The ECC key agreement is wc_ecc_shared_secret.
The AES encrypt decrypt functions depend on the mode. AES CBC for example is: wc_AesCbcEncrypt and wc_AesCbcDecrypt.

If you are looking for something more lightweight to securely exchange messages you could look at our ECC encrypt example here:
https://github.com/wolfSSL/wolfssl-exam … aster/btle

Thanks,
David Garske, wolfSSL

346

(1 replies, posted in wolfSSL)

Hi bthoms01,

Usually this error means there was an issue placing network bytes into the read buffer.

You have `MQX_USE_IO_OLD` defined which causes the wolfio.c to use the old MQX RTCS. You might try adding some debug in the IO and doing a Wireshark trace.

Another option is to enable and set IO callbacks where you can handle the socket read/writes directly. To do this define `WOLFSSL_USER_IO` and set IO callbacks using:
WOLFSSL_API void wolfSSL_SetIORecv(WOLFSSL_CTX *ctx, CallbackIORecv CBIORecv);
WOLFSSL_API void wolfSSL_SetIOSend(WOLFSSL_CTX *ctx, CallbackIOSend CBIOSend);

You can find an example for this here:
https://github.com/wolfSSL/wolfssl-exam … ack.c#L194

If you don't require support for pre TLS 1.2 I'd recommend adding `NO_OLD_TLS`.

Let me know if that information is helpful or if you have any other questions.

Thanks,
David Garske, wolfSSL

Hi Ravi,

Thanks for the report. I was able to reproduce a build error with `./configure --disable-ecc -enable-tls13 && make`, so I've issued a PR for it here:
https://github.com/wolfSSL/wolfssl/pull/1187
https://github.com/wolfSSL/wolfssl/pull … 639fbL5059

Marking this forum case as solved.

Thanks,
David Garske, wolfSSL

Hi Ravi,

The ECC algorithm is only on by default wit the `x86_64` platform. Please try using `./configure --enable-ecc --enable-tls13`. If that doesn't work can you provide the wolfSSL version (or Git commit #) along with which platform you are building on?

Thanks,
David Garske, wolfSS

Hi Kackle123,

Thanks for the report. I've pushed a fix in PR #39 here:
https://github.com/wolfSSL/wolfMQTT/pull/39

David Garske, wolfSSL

Hi Eyal,

That's wonderful! Very happy you got it all working.
Let me know if you have any other questions or issues.

Cheers,
David Garske