Hi iskim,

Welcome to the wolfSSL Forums.

The MQTT protocol uses a keep-alive message called a ping to sustain the communication channel between a client and the broker. During the client connect, the keep_alive_sec field is sent to broker, which uses that to determine if the client has lost it's connection. Some brokers use that value (in seconds) times 1.5 to finally disconnect the client. If your client is not sending the ping (or ping response) within the time frame negotiated, then the broker will disconnect the client.

> - Under what circumstances does WolfMQTT trigger a NETWORK error?

A network timeout can occur when the client attempts to read or write data to the network, but the operation takes too long. This is configurable with the timeout_ms parameter when calling MqttClient_NetConnect.

> - Are there any specific configurations or common pitfalls that I should look into to prevent this kind of disconnection?

A network error might not even be on client side. The application should handle network problems gracefully and allow reconnection attempts.


Could you tell us more about your MQTT project and your location for our support records? Feel free to email us at support@wolfssl.com for a more private conversation.

Kind regards,
Eric - wolfSSL Support

Hi Andids

Welcome to the wolfSSL Forums.

Could you tell us a bit about your Curl project and your location for our support records?

Did you review the Cmake instructions?
https://github.com/curl/curl/blob/maste … L-CMAKE.md

Thanks,
Eric - wolfSSL Support

28

(3 replies, posted in wolfSSL)

Hi Dwayne,

Thanks for sharing these details. AWS has several requirements for TLS versions and extensions. It might be worthwhile to try updating the wolfSSL version. The latest release is v5.7.2

If this is related to a commercial project, you should open a new issue by emailing support@wolfssl.com or through the zendesk portal at https://wolfssl.zendesk.com.

29

(3 replies, posted in wolfSSL)

Hi Dwayne,

Welcome to the wolfSSL Forums.

Could you tell us a bit about your project and your location for our support records?

There is not a clear error in the log you shared. It could be that the peer sent an alert, but I would have expected to see that recorded in the log. Are you able to generate a packet capture of the failing handshake?

We always recommend using the latest version of the library. Often we have already resolved issues that you may be experiencing.

Is this a new failure that was previously working? Do you know what changed?

Lastly, if you'd prefer, you can open a support ticket by emailing support@wolfssl.com

Thanks,
Eric - wolfSSL Support

Hello Victor,

Welcome to the wolfSSL Forums.

We were excited to see ExpressVPN utilize some of our latest developments, DTLS 1.3 in particular:
https://www.wolfssl.com/expressvpn-is-t … a-wolfssl/

And in fact, the lightway-core is open source!
https://github.com/expressvpn/lightway-core

Could you tell us a bit about your project and your location for our support records?

Thanks,
Eric - wolfSSL Support

31

(3 replies, posted in wolfSSL)

I've requested our business director, Scott McClung, to reach out to set up a call with our engineers. Please keep an eye out for an email.

Thanks,
Eric - wolfSSL Support

32

(3 replies, posted in wolfSSL)

Hi wirediot,

Welcome to the wolfSSL Forums. Could you tell us a bit about your project using wolfSSL and where you are located for our support records?

The default cert verification logic in wolfSSL is more stringent (secure) than other SSL libs in that we require the root CA to be loaded, as opposed to verifying the peer cert based on any cert that matches. You can loosen this requirement by enabling the define WOLFSSL_ALT_CERT_CHAINS.

https://github.com/wolfSSL/wolfssl/blob … .c#L33-L37
* WOLFSSL_ALT_CERT_CHAINS:
*     Allows CA's to be presented by peer, but not part of a valid chain.
*     Default wolfSSL behavior is to require validation of all presented peer
*     certificates. This also allows loading intermediate CA's as trusted
*     and ignoring no signer failures for CA's up the chain to root.

So to answer your questions:

1. Is this implementation in accordance to RFC?  what part of RFC does this comply to that we need to absolute load "A"?

Yes

2. What changes are needed in embeddedSSL if we just need to validate using B or C?

See discussion above.

3. from a security perspective, I understand both are secure and loading A does not mean it is more secure, but isnt B or C more likely to be revoked rather than A?

Root certs are much less frequently revoked, but it can happen. Which is why things like OCSP exist.

5. if there are multiple flavors of B and C, wouldn't it be safer to just load A and let device validate B/C/D through chain validation?

Yes!

5. do we know if all the SSL clients operate same way (openSSL, mbedTLS, etc)?

They are definitely different.

Thanks,
Eric - wolfSSL Support

33

(1 replies, posted in wolfMQTT)

Hello valschroeder

Welcome to the wolfSSL Forums. Yes, wolfMQTT sounds like a great fit for your project!

We have lots of example projects in the library. I'm not sure what you mean by "manual work to handle incoming messages". The client subscribes to a topic and messages are received.

Could you tell us a bit about your MQTT project and where you are located for our support records?

Thanks,
Eric - wolfSSL Support

Hi gabriel,

Welcome to the wolfSSL Forums. Could you tell us a bit about your project using wolfSSL and where you are from for our support records?

We have a benchmarking tool that will be of interest to you:
https://github.com/wolfSSL/wolfssl/tree … /benchmark

The ED448 sign operation does perform a hash also:
https://github.com/wolfSSL/wolfssl/blob … 448.c#L355

The "ph" is for pre-hashed, signifying that the message is pre-hashed before the signature calculation.

Thanks,
Eric - wolfSSL Support

35

(9 replies, posted in wolfCrypt)

Is the compiler in the environment path? Can you invoke it from the command line right there?

36

(1 replies, posted in wolfSSL)

Hi DDaugher

Welcome to the wolfSSL Forums.

Yes, AES-GCM is a good candidate. You can check out the wolfSSL crypto benchmarking tool to get a better idea of throughputs.
https://github.com/wolfSSL/wolfssl/tree … /benchmark

We also have several excellent examples in this other repository:
https://github.com/wolfSSL/wolfssl-examples
https://github.com/wolfSSL/wolfssl-exam … crypto/aes

Could you tell us a bit about your project? Feel free to email us at support@wolfssl.com for a more private conversation.

Thanks,
Eric - wolfSSL Support

37

(9 replies, posted in wolfCrypt)

Can you try using WSL to install the PPC compiler and build the wolfSSL lib there?

38

(9 replies, posted in wolfCrypt)

I'm not going to say its impossible, but certainly it will be more straightforward on Linux.

39

(9 replies, posted in wolfCrypt)

When you set up the cross compilation in the configure step, the tools will have that macro available.
https://www.wolfssl.com/documentation/m … ss-compile

40

(9 replies, posted in wolfCrypt)

Hi asn,

Welcome to the wolfSSL Forums.

You should not add configuration defines in the source files. This will always result in undefined behavior.

This is the preferred method for configuring the library:
https://www.wolfssl.com/using-user_settings-h-wolfssl/

Yes, you can build wolfSSL for PPC. The environment variable `__ppc__` will be detected to set up the correct settings for that architecture.

Let us know if there are questions.

Thanks,
Eric - wolfSSL Support

41

(3 replies, posted in wolfCrypt)

Hi James,

Please email support@wolfssl.com for a discussion about FIPS impacts.

42

(3 replies, posted in wolfCrypt)

Hello James,

Thanks for joining the wolfSSL Forums. wolfSSL does not currently support ECC571. I can help you open an official feature request. Please email support@wolfssl.com to get the process started.

Kind regards,
Eric - wolfSSL Support

Servers often do not support bidirectional shutdown, instead just silently closing the connection.

In the case of DTLS, a time out while waiting for the close notify could be used to handle the case of a non-responding server.

Hi bp787

Are you trying to do a bi-directional shutdown?

Does the server respond with anything after the first shutdown? Do you have a pcap of the interaction?

Thanks,
Eric - wolfSSL Support

45

(1 replies, posted in wolfSSL)

That protocol is not currently supported in wolfSSL, but we do accept feature requests. You can start the process by emailing support@wolfssl.com

46

(2 replies, posted in wolfCrypt)

Hello Jens,

Thanks for joining the wolfSSL Forums.

Yes, we implemented Karatsuba in 2022:
https://github.com/wolfSSL/wolfssl/pull/4853
You'll see some comparison benchmarks in the comments of that PR

Have you checked out our wolfBoot project?
https://github.com/wolfSSL/wolfBoot
https://github.com/wolfSSL/wolfBoot/blo … md#stm32h7

Feel free to email us at support@wolfssl.com with any questions.

Kind regards,
Eric - wolfSSL Support

Hello mrinalilothey

Welcome to the wolfSSL Forums.

We have some example projects for IAR Workbench to get you started:
https://github.com/wolfSSL/wolfssl/tree … /IAR-EWARM

Let us know if there are questions. You can always open a support ticket by emailing support@wolfssl.com

Could you tell us a bit about your project using wolfSSL?

Thanks,
Eric - wolfSSL Support

Hi Nicolas,

Welcome to the forums!

My colleague is going to review and provide a response for you.

Thanks,
Eric - wolfSSL Support

49

(12 replies, posted in wolfSSL)

Hi invoker,

I would recommend opening a support ticket by emailing support@wolfssl.com

Thanks,
Eric

50

(12 replies, posted in wolfSSL)

I just meant that maybe you could setup a reproducer using the certs you are trying