Hello @kevinpt,

Thanks for contacting wolfSSL Support.

Yes, I see what you mean about not being able to re-iterate the list. In fact this in src/ssl.c@18435

    /* already went through them */
    if (cert->altNamesNext == NULL)
        return NULL;

So maybe a new API as you suggested, wolfSSL_X509_get_first_altname(), that will simply reset the list pointer to the head? I review this with the team tomorrow evening.

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

178

(7 replies, posted in wolfMQTT)

The socket handling is the responsibility of the application's implementation of the MqttNet structure. The example does this here:
https://github.com/wolfSSL/wolfMQTT/blo … et.c#L1048

The wolfSSL_shutdown API is used to send the FIN packet to a peer, indicating that the application will no longer listen to that socket. The wolfSSL_shutdown API is used by the client as part of a bi-directional shutdown, but otherwise is not needed at the client side. It does not clean up the socket resource.

There is built-in memory tracking in wolfSSL:

-DWOLFSSL_TRACK_MEMORY

or

./configure --enable-trackmemory

Also memory logging:

-DWOLFSSL_MEMORY_LOG

or

--enable-memorylog

179

(7 replies, posted in wolfMQTT)

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.

180

(7 replies, posted in wolfMQTT)

Hello @kackle123

Thanks for contacting wolfSSL Support. Calling wolfSSL_shutdown is not required, since the broker will disconnect the socket connection after the client sends the disconnect packet (MqttClient_Disconnect). The wolfSSL resources are freed using the code in MqttSocket_Disconnect:
https://github.com/wolfSSL/wolfMQTT/blo … ket.c#L465

Could there be an allocation in the application TLS setup callback? In the examples, we use mqtt_tls_cb
https://github.com/wolfSSL/wolfMQTT/blo … ple.c#L505

Thanks,
Eric @wolfSSL Support

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 @agubisch

Have you tested the firmware push  example as-is with the PIC32? Does it also demonstrate the issue you are seeing?

Thanks,
Eric @ wolfSSL Support

183

(2 replies, posted in wolfMQTT)

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

184

(5 replies, posted in wolfMQTT)

Hi JazP,

Yes, please open a support ticket.

Thanks,
Eric @ wolfSSL Support

185

(5 replies, posted in wolfMQTT)

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

186

(5 replies, posted in wolfMQTT)

Hello @JazP

Thanks for contacting wolfSSL Support. The `stat` structure element is used internally by the command API. It preserves the current state of the command processing. This functionality is used by the non-blocking configuration option, when the API could return `MQTT_CODE_CONTINUE` to indicate an incomplete command.

If you are reusing the structure for a subsequent call (for example calling publish twice in a row with the same structure), you would need to reset the stat to 0 (MQTT_MSG_BEGIN).

Could you tell us a bit more about your use case? Feel free to contact us at support@wolfssl.com

Thanks,
Eric

Edit to add info about the "ack" - The ack packet is a response from the broker to indicate the status of the requested command.

187

(1 replies, posted in wolfMQTT)

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.

Good to hear that you were able to resolve the issue.

Thanks again for contacting wolfSSL and best of luck with your project!

189

(7 replies, posted in wolfSSL (formerly CyaSSL))

Hi Okba,

The callbacks are generally used for setting up a hardware based encryption engine. Could you tell us more about your project? Please feel free to use support@wolfssl.com if you'd prefer to keep the thread private.

Kind regards,

Eric Blankenhorn
wolfSSL Support

Hello @I_AM_MAD

Thank you for contacting wolfSSL Support. What are are you minimum requirements, both in terms of functionality and ROM/RAM size?

We have a comprehensive guide to optimizing the wolfSSL library:
https://www.wolfssl.com/docs/tuning-guide/

If you still have questions please feel free to ask here or at support@wolfssl.com

Kind regards,

Eric Blankenhorn
wolfSSL Support

Hi Kamal,

Thanks for reaching out to wolfSSL.

We have a bare-metal example for the older KEIL software packs but I'm unsure if they would work out of the box for the MDK4 on LPC3250.

You can have a look at the following link:
https://github.com/wolfSSL/wolfssl/tree … DE/MDK-ARM

Please let us know if it works for you.

Best Regards,
Eric Blankenhorn
wolfSSL Support

Hi Ben,

That's great news on the config settings!

The cipher suites we support are static NTRU ones. So what we currently support is an option of RSA or NTRU, but not both. The use of both at the same time can only be done currently with QSH, which is an extension to add some random data to the pms using NTRU.

More about QSH:
https://www.wolfssl.com/quantum-safe-wolfssl-2/

Kind regards,
Eric
wolfSSL Support

Hello @Benon

Thank you for contacting wolfSSL support. Could you post the actual settings header file you are using?

Thanks,
Eric
wolfSSL Support

Hi @niemilkm,

I see some similar problems when searching for this issue:
https://stackoverflow.com/questions/422 … -directory

Thanks,
Eric
wolfSSL Support

Hi Gil,

Thank you for providing more information. The "connect" API is outside of the wolfMQTT library. Can you reproduce this problem with any of the other Harmony network examples?

Thanks,
Eric Blankenhorn
wolfSSL Support

Hi Gil,

Thanks for contacting wolfSSL support. I see that there was a bugfix that may pertain to the issue you are having:
https://github.com/wolfSSL/wolfMQTT/issues/88

Could you check and see if this fixes the issue of MqttClient_NetConnect() returning rc == MQTT_CODE_CONTINUE forever ?

Thanks,
Eric Blankenhorn
wolfSSL Support

197

(5 replies, posted in wolfMQTT)

Hi Peter,

I fixed the issue you reported with MqttClient_Publish_ex. You can review the update in https://github.com/wolfSSL/wolfMQTT/pull/95

Thanks,
Eric Blankenhorn
wolfSSL Support

198

(5 replies, posted in wolfMQTT)

Hi Peter,

I'm glad you had an opportunity to test the changes and thank you for your feedback. I will have a look into the return value from MqttClient_Publish_ex. I think your suspicion is correct regarding the publish throughput.

Thanks,
Eric Blankenhorn
wolfSSL Support

199

(5 replies, posted in wolfMQTT)

Hi PeterL,

The new methods for publishing are available to review in https://github.com/wolfSSL/wolfMQTT/pull/92

This update adds two methods: A callback that is executed from the new MqttClient_Publish_ex API; and it is now possible to simply call MqttClient_Publish successively when the payload buffer size is smaller than the total payload size as set in the MqttPublish structure parameter. The example for the client firmware push was modified to use the new publish callback.

Best regards,
Eric Blankenhorn,
wolfSSL Support

There was some existing code to handle the device serial number OID, but it was missing from the structures you were attempting to use. I added serial number elements to the Cert and DecodedCert structures, and modified the internal methods to support these. You can review these changes in https://github.com/wolfSSL/wolfssl/pull/1826

Thanks,
Eric B
wolfSSL Support