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

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

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.

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

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

Hello @Benon

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

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

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

Hi @KamKon,

Great to hear that you have the library working correctly now. Do you have any further questions or issues?

Best regards,

Eric Blankenhorn
wolfSSL Support

Hi Kamil,

I am looking into the issue you reported. Could you also send a packet capture of the two cases?

Best regards,

Eric Blankenhorn
wolfSSL Support

Hi Sam Sam,

I am trying to reproduce the issues you have reported. For now I would like to try using only wolfSSL, we can add CURL in later.

I have configured wolfSSL using:

$ ./configure --enable-all

I am able to connect to the "www.tvnow.de" host using the example client:

$ ./examples/client/client -h 217.118.168.60 -p 443 -d -x -C -g -i
peer's cert info:
 issuer : /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.tvnow.de
 altname = tvnow.de
 altname = *.tvnow.de
 serial number:1c:6b:0d:e8:9a:44:80:03:c3:a1:0e:03:bd:8e:6a:92 
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
SSL curve name is SECP256R1
Client Random : C70D72DD1A0B6FD211139FF47EF63367DB43A16D7A3AC3807CF5C8649B4B1021
SSL connect ok, sending GET...
HTTP/1.0 302 Found
Location: https://www.tvnow.de/index.html
Server: BigIP
C
onnection: close
Content-Length: 0

Also, I can specify the SSL version with the "-v <num>" option:

./examples/client/client -h 217.118.168.60 -p 443 -d -x -C -g -i -v 2
./examples/client/client -h 217.118.168.60 -p 443 -d -x -C -g -i -v 3

Only the values 2 and 3 for SSL version are successful with that host.

Does this match your results so far?

Thanks,
Eric Blankenhorn
wolfSSL Support