Giter Site home page Giter Site logo

wolfssl / wolfmqtt Goto Github PK

View Code? Open in Web Editor NEW
518.0 55.0 155.0 1.73 MB

wolfMQTT is a small, fast, portable MQTT client implementation, including support for TLS 1.3.

Home Page: https://www.wolfssl.com

License: GNU General Public License v2.0

Shell 3.26% C 59.32% Makefile 2.35% M4 19.45% C++ 1.22% CMake 13.81% FreeMarker 0.46% Batchfile 0.15%
mqtt-client wolfssl mqtt tls mqqt-packet wolfssl-library mqtt-tls sensor-network mqtt-sn tls13-support

wolfmqtt's Introduction

wolfMQTT

This is an implementation of the MQTT Client written in C for embedded use, which supports SSL/TLS via the wolfSSL library. This library was built from the ground up to be multi-platform, space conscious and extensible. Integrates with wolfSSL to provide TLS support.

For details on wolfMQTT see the wolfMQTT Manual.

Building

Mac/Linux/Unix

  1. ./autogen.sh (if cloned from GitHub)
  2. ./configure (to see a list of build options use ./configure --help)
  3. make
  4. sudo make install

Notes:

  • If wolfssl was recently installed, run sudo ldconfig to update the linker cache.
  • Debug messages can be enabled using --enable-debug or --enable-debug=verbose (for extra logging).
  • For a list of build options run ./configure --help.
  • The build options are generated in a file here: wolfmqtt/options.h.

Windows Visual Studio

For building wolfMQTT with TLS support in Visual Studio:

  1. Open the <wolfssl-root>/wolfssl64.sln.
  2. Re-target for your Visual Studio version (right-click on solution and choose Retarget solution).
  3. Make sure the Debug DLL or Release DLL configuration is selected. Make note if you are building 32-bit x86 or 64-bit x64.
  4. Build the wolfSSL solution.
  5. Copy the wolfssl.lib and wolfssl.dll files into <wolfmqtt-root>.
    • For DLL Debug with x86 the files are in: DLL Debug.
    • For DLL Release with x86 the files are in: DLL Release.
    • For DLL Debug with x64 the files are in: x64/DLL Debug.
    • For DLL Release with x64 the files are in: x64/DLL Release.
  6. Open the <wolfmqtt-root>/wolfmqtt.sln solution.
  7. Make sure you have the same architecture (x86 or x64 selected) as used in wolfSSL above.
  8. By default the include path for the wolfssl headers is ./../wolfssl/. If your wolfssl root location is different you can go into the project settings and adjust this in C/C++ -> General -> Additional Include Directories.
  9. Configure your Visual Studio build settings using wolfmqtt/vs_settings.h.
  10. Build the wolfMQTT solution.

CMake

CMake supports compiling in many environments including Visual Studio if CMake support is installed. The commands below can be run in Developer Command Prompt.

mkdir build
cd build
# to use installed wolfSSL location (library and headers)
cmake .. -DWITH_WOLFSSL=/prefix/to/wolfssl/install/
# OR to use a wolfSSL source tree
cmake .. -DWITH_WOLFSSL_TREE=/path/to/wolfssl/
# build
cmake --build .

vcpkg

You can download and install wolfMQTT using the vcpkg:

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
OR for Windows
bootstrap-vcpkg.bat

./vcpkg integrate install
./vcpkg install wolfmqtt

The wolfMQTT port in vcpkg is kept up to date by wolfSSL.

We also have vcpkg ports for wolftpm, wolfssl and curl.

Arduino

See README.md at IDE/ARDUINO.README.md

MinGW

export PATH="/opt/mingw-w32-bin_i686-darwin/bin:$PATH"
export PREFIX=$PWD/build

# wolfSSL
cd wolfssl
./configure --host=i686 CC=i686-w64-mingw32-gcc LD=i686-w64-mingw32-ld CFLAGS="-DWIN32 -DMINGW -D_WIN32_WINNT=0x0600" LIBS="-lws2_32 -L$PREFIX/lib -lwolfssl" --prefix=$PREFIX
make
make install

# wolfMQTT
cd ../wolfmqtt
./configure --host=i686 CC=i686-w64-mingw32-gcc LD=i686-w64-mingw32-ld CFLAGS="-DWIN32 -DMINGW -D_WIN32_WINNT=0x0600 -DBUILDING_WOLFMQTT -I$PREFIX/include" LDFLAGS="-lws2_32 -L$PREFIX/lib -lwolfssl" --prefix=$PREFIX --disable-examples
make

Zephyr RTOS

Support for Zephyr is available in the zephyr directory. For instructions on how to build for Zephyr, see the README.md.

Architecture

The library has three components.

1. mqtt_client

This is where the top level application interfaces for the MQTT client reside.

  • int MqttClient_Init(MqttClient *client, MqttNet *net, MqttMsgCb msg_cb, byte *tx_buf, int tx_buf_len, byte *rx_buf, int rx_buf_len, int cmd_timeout_ms);

These API's are blocking on MqttNet.read until error/timeout (cmd_timeout_ms):

  • int MqttClient_Connect(MqttClient *client, MqttConnect *connect);
  • int MqttClient_Publish(MqttClient *client, MqttPublish *publish);
  • int MqttClient_Subscribe(MqttClient *client, MqttSubscribe *subscribe);
  • int MqttClient_Unsubscribe(MqttClient *client, MqttUnsubscribe *unsubscribe);
  • int MqttClient_Ping(MqttClient *client);
  • int MqttClient_Disconnect(MqttClient *client);

This function blocks waiting for a new publish message to arrive for a maximum duration of timeout_ms.

  • int MqttClient_WaitMessage(MqttClient *client, MqttMessage *message, int timeout_ms);

These are the network connect / disconnect interfaces that wrap the MqttNet callbacks and handle WolfSSL TLS:

  • int MqttClient_NetConnect(MqttClient *client, const char* host, word16 port, int timeout_ms, int use_tls, MqttTlsCb cb);
  • int MqttClient_NetDisconnect(MqttClient *client);

Helper functions:

  • const char* MqttClient_ReturnCodeToString(int return_code);

2. mqtt_packet

This is where all the packet encoding/decoding is handled.

The header contains the MQTT Packet structures for:

  • Connect: MqttConnect
  • Publish / Message: MqttPublish / MqttMessage (they are the same)
  • Subscribe: MqttSubscribe
  • Unsubscribe: MqttUnsubscribe

3. mqtt_socket

This is where the transport socket optionally wraps TLS and uses the MqttNet callbacks for the platform specific network handling.

The header contains the MQTT Network structure MqttNet for network callback and context.

Implementation

Here are the steps for creating your own implementation.

  1. Create network callback functions for Connect, Read, Write and Disconnect. See examples/mqttnet.c and examples/mqttnet.h.
  2. Define the callback functions and context in a MqttNet structure.
  3. Call MqttClient_Init passing in a MqttClient structure pointer, MqttNet structure pointer, MqttMsgCb function pointer, TX/RX buffers with maximum length and command timeout.
  4. Call MqttClient_NetConnect to connect to broker over network. If use_tls is non-zero value then it will perform a TLS connection. The TLS callback MqttTlsCb should be defined for wolfSSL certificate configuration.
  5. Call MqttClient_Connect passing pointer to MqttConnect structure to send MQTT connect command and wait for Connect Ack.
  6. Call MqttClient_Subscribe passing pointer to MqttSubscribe structure to send MQTT Subscribe command and wait for Subscribe Ack (depending on QoS level).
  7. Call MqttClient_WaitMessage passing pointer to MqttMessage to wait for incoming MQTT Publish message.

Examples

Client Example

The example MQTT client is located in /examples/mqttclient/. This example exercises many of the exposed API’s and prints any incoming publish messages for subscription topic “wolfMQTT/example/testTopic”. This client contains examples of many MQTTv5 features, including the property callback and server assignment of client ID. The mqqtclient example is a good starting template for your MQTT application.

Simple Standalone Client Example

The example MQTT client is located in /examples/mqttsimple/. This example demonstrates a standalone client using standard BSD sockets. This requires HAVE_SOCKET to be defined, which comes from the ./configure generated wolfmqtt/config.h file. All parameters are build-time macros defined at the top of /examples/mqttsimple/mqttsimple.c.

Non-Blocking Client Example

The example MQTT client is located in /examples/nbclient/. This example uses non-blocking I/O for message exchange. The wolfMQTT library must be configured with the --enable-nonblock option (or built with WOLFMQTT_NONBLOCK).

Firmware Example

The MQTT firmware update is located in /examples/firmware/. This example has two parts. The first is called “fwpush”, which signs and publishes a firmware image. The second is called “fwclient”, which receives the firmware image and verifies the signature. This example publishes message on the topic “wolfMQTT/example/firmware”. The "fwpush" application is an example of using a publish callback to send the payload data.

Azure IoT Hub Example

We setup a wolfMQTT IoT Hub on the Azure server for testing. We added a device called demoDevice, which you can connect and publish to. The example demonstrates creation of a SasToken, which is used as the password for the MQTT connect packet. It also shows the topic names for publishing events and listening to devicebound messages. This example only works with ENABLE_MQTT_TLS set and the wolfSSL library present because it requires Base64 Encode/Decode and HMAC-SHA256. Note: The wolfSSL library must be built with ./configure --enable-base64encode or #define WOLFSSL_BASE64_ENCODE. The wc_GetTime API was added in 3.9.1 and if not present you'll need to implement your own version of this to get current UTC seconds or update your wolfSSL library. NOTE The Azure broker only supports MQTT v3.1.1

AWS IoT Example

We setup an AWS IoT endpoint and testing device certificate for testing. The AWS server uses TLS client certificate for authentication. The example is located in /examples/aws/. The example subscribes to $aws/things/"AWSIOT_DEVICE_ID"/shadow/update/delta and publishes to $aws/things/"AWSIOT_DEVICE_ID"/shadow/update. NOTE The AWS broker only supports MQTT v3.1.1

Watson IoT Example

This example enables the wolfMQTT client to connect to the IBM Watson Internet of Things (WIOT) Platform. The WIOT Platform has a limited test broker called "Quickstart" that allows non-secure connections to exercise the component. The example is located in /examples/wiot/. Works with MQTT v5 support enabled. NOTE The WIOT Platform will be disabled DEC2023. The demo may still be useful for users of IBM Watson IOT.

MQTT-SN Example

The Sensor Network client implements the MQTT-SN protocol for low-bandwidth networks. There are several differences from MQTT, including the ability to use a two byte Topic ID instead the full topic during subscribe and publish. The SN client requires an MQTT-SN gateway. The gateway acts as an intermediary between the SN clients and the broker. This client was tested with the Eclipse Paho MQTT-SN Gateway, which connects by default to the public Eclipse broker, much like our wolfMQTT Client example. The address of the gateway must be configured as the host. The example is located in /examples/sn-client/.

More about MQTT-SN examples in examples/sn-client/README.md

Multithread Example

This example exercises the multithreading capabilities of the client library. The client implements two tasks: one that publishes to the broker; and another that waits for messages from the broker. The publish thread is created NUM_PUB_TASKS times (5 by default) and sends unique messages to the broker. This feature is enabled using the --enable-mt configuration option. The example is located in /examples/multithread/.

The multi-threading feature can also be used with the non-blocking socket (--enable-nonblock).

If you are having issues with thread synchronization on Linux consider using not the conditional signal (WOLFMQTT_NO_COND_SIGNAL).

Atomic publish and subscribe examples

In the examples/pub-sub folder, there are two simple client examples:

  • mqtt-pub - publishes to a topic
  • mqtt-sub - subscribes to a topic and waits for messages

These examples are useful for quickly testing or scripting.

Example Options

The command line examples can be executed with optional parameters. To see a list of the available parameters, add the -?

 ./examples/mqttclient/mqttclient -?
mqttclient:
-?          Help, print this usage
-h <host>   Host to connect to, default: test.mosquitto.org
-p <num>    Port to connect on, default: Normal 1883, TLS 8883
-t          Enable TLS
-A <file>   Load CA (validate peer)
-K <key>    Use private key (for TLS mutual auth)
-c <cert>   Use certificate (for TLS mutual auth)
-S <str>    Use Host Name Indication, blank defaults to host
-q <num>    Qos Level 0-2, default: 0
-s          Disable clean session connect flag
-k <num>    Keep alive seconds, default: 60
-i <id>     Client Id, default: WolfMQTTClient
-l          Enable LWT (Last Will and Testament)
-u <str>    Username
-w <str>    Password
-m <str>    Message, default: test
-n <str>    Topic name, default: wolfMQTT/example/testTopic
-r          Set Retain flag on publish message
-C <num>    Command Timeout, default: 30000ms
-P <num>    Max packet size the client will accept, default: 1048576
-T          Test mode
-f <file>   Use file contents for publish

The available options vary depending on the library configuration.

Broker compatibility

wolfMQTT client library has been tested with the following brokers:

  • Adafruit IO by Adafruit
  • AWS by Amazon
  • Azure by Microsoft
  • flespi by Gurtam
  • HiveMQ and HiveMQ Cloud by HiveMQ GmbH
  • IBM WIoTP Message Gateway by IBM
  • Mosquitto by Eclipse
  • Paho MQTT-SN Gateway by Eclipse
  • VerneMQ by VerneMQ/Erlio
  • EMQX broker

Specification Support

MQTT v3.1.1 Specification Support

The initially supported version with full specification support for all features and packets type such as:

  • QoS 0-2
  • Last Will and Testament (LWT)
  • Client examples for: AWS, Azure IoT, Firmware update, non-blocking and generic.

MQTT v5.0 Specification Support

The wolfMQTT client supports connecting to v5 enabled brokers when configured with the --enable-v5 option. The following v5.0 specification features are supported by the wolfMQTT client:

  • AUTH packet
  • User properties
  • Server connect ACK properties
  • Format and content type for publish
  • Server disconnect
  • Reason codes and strings
  • Maximum packet size
  • Server assigned client identifier
  • Subscription ID
  • Topic Alias

The v5 enabled wolfMQTT client was tested with the following MQTT v5 brokers:

  • Mosquitto ** Runs locally. ** ./examples/mqttclient/mqttclient -h localhost
  • Flespi ** Requires an account tied token that is regenerated hourly. ** ./examples/mqttclient/mqttclient -h "mqtt.flespi.io" -u "<your-flespi-token>"
  • VerneMQ MQTTv5 preview ** Runs locally. ** ./examples/mqttclient/mqttclient -h localhost
  • HiveMQ 4.0.0 EAP ** Runs locally. ** ./examples/mqttclient/mqttclient -h localhost
  • HiveMQ Cloud ** ./examples/mqttclient/mqttclient -h 833f87e253304692bd2b911f0c18dba1.s1.eu.hivemq.cloud -t -S -u wolf1 -w NEZjcm7i8eRjFKF -p 8883
  • EMQX broker ** ./examples/mqttclient/mqttclient -h "broker.emqx.io"

Properties are allocated from a local stack (size MQTT_MAX_PROPS) by default. Define WOLFMQTT_DYN_PROP to use malloc for property allocation.

MQTT Sensor Network (MQTT-SN) Specification Support

The wolfMQTT SN Client implementation is based on the OASIS MQTT-SN v1.2 specification. The SN API is configured with the --enable-sn option. There is a separate API for the sensor network API, which all begin with the "SN_" prefix. The wolfMQTT SN Client operates over UDP, which is distinct from the wolfMQTT clients that use TCP. The following features are supported by the wolfMQTT SN Client:

  • Register
  • Will topic and message set up
  • Will topic and message update
  • All QoS levels
  • Variable-sized packet length field

Unsupported features:

  • Automatic gateway discovery is not implemented
  • Multiple gateway handling

The SN client was tested using the Eclipse Paho MQTT-SN Gateway (https://github.com/eclipse/paho.mqtt-sn.embedded-c) running locally and on a separate network node. Instructions for building and running the gateway are in the project README.

Post-Quantum MQTT Support

Recently the OpenQuantumSafe project has integrated their fork of OpenSSL with the mosquito MQTT broker. You can now build wolfMQTT with wolfSSL and liboqs and use that to publish to the mosquito MQTT broker. Currently, wolfMQTT supports the KYBER_LEVEL1 and P256_KYBER_LEVEL1 groups and FALCON_LEVEL1 for authentication in TLS 1.3. This works on Linux.

Getting Started with Post-Quantum Mosquito MQTT Broker and Subscriber

To get started, you can use the code from the following github pull request:

open-quantum-safe/oqs-demos#143

Follow all the instructions in README.md and USAGE.md. This allows you to create a docker image and a docker network. Then you will run a broker, a subscriber and a publisher. At the end the publisher will exit and the broker and subscriber will remain active. You will need to re-activate the publisher docker instance and get the following files onto your local machine:

  • /test/cert/CA.crt
  • /test/cert/publisher.crt
  • /test/cert/publisher.key

NOTE: Do not stop the broker and the subscriber instances.

Building and Running Post-Quantum wolfMQTT Publisher

Follow the instructions for obtaining and building liboqs and building wolfSSL in section 15 of the following document:

https://github.com/wolfSSL/wolfssl/blob/master/INSTALL

No special flags are required for building wolfMQTT. Simply do the following:

./autogen.sh (if obtained from github)
./configure
make all
make check

Since the broker and subscriber are still running, you can use mqttclient to publish using post-quantum algorithms in TLS 1.3 by doing the following:

./examples/mqttclient/mqttclient -h 172.18.0.2 -t -A CA.crt -K publisher.key -c publisher.crt -m "Hello from post-quantum wolfMQTT!!" -n test/sensor1 -Q KYBER_LEVEL1

Congratulations! You have just published an MQTT message using TLS 1.3 with the KYBER_LEVEL1 KEM and FALCON_LEVEL1 signature scheme. To use the hybrid group, replace KYBER_LEVEL1 with P256_KYBER_LEVEL1.

Curl Easy Socket Support

wolfMQTT now supports using libcurl's easy socket interface as a backend. When enabled, wolfMQTT will use the libcurl API for the socket backend, and libcurl will use wolfSSL to negotiate TLS. This can be enabled with --enable-curl.

At this time wolfMQTT's libcurl option supports both TLS and mTLS, but not Post-Quantum TLS.

How to use libcurl with wolfMQTT

To use wolfMQTT with libcurl and wolfSSL:

  • build wolfssl with --enable-curl and install to /usr/local.
  • build libcurl with --with-wolfssl and install to /usr/local.

Finally, build wolfMQTT with --enable-curl.

Supported Build Options

The --enable-curl option works with these combinations:

  • --enable-mt
  • --enable-nonblock
  • --enable-tls (default enabled)
  • --enable-timeout (default enabled)

However --enable-curl is incompatible and not supported with these options:

  • --enable-all
  • --enable-sn

Stress Build Option

To simplify testing a stress build option has been added, --enable-stress=[args]. The Stress option enables multithreading and nonblocking, and adds defines for TEST_NONBLOCK, NUM_PUB_TASKS, and NUM_PUB_PER_TASK.

Examples of useage:

  • --enable-stress: stress with default options.
  • --enable-stress=t7,p8: stress with 7 threads, and 8 publishes per thread.
  • --enable-stress=t7,p8 --enable-curl: same as above, but with curl backend.

Note: When stress is enabled, the Multithread Example becomes localhost only and will not connect to remote servers. Additionally the test scripts/stress.test is added to make check, and all other tests are disabled.

wolfmqtt's People

Contributors

anhu avatar bandi13 avatar billphipps avatar cconlon avatar danielinux avatar davidkorczynski avatar dgarske avatar douzzer avatar ejohnstown avatar embhorn avatar gojimmypi avatar guidovranken avatar haydenroche5 avatar jacobbarthelmeh avatar julek-wolfssl avatar kaleb-himes avatar kareem-wolfssl avatar kojo1 avatar lealem47 avatar nekoman2187 avatar philljj avatar quinnmiller1997 avatar toddouska avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wolfmqtt's Issues

WolfSSL / wolfMQTT is using a large size of stack

Hi,

I am running the "mqttexample.c" and everything is working as expected. My problem is that it requires a large stack. I have a feeling that it could be some settings in "settings.h". Here are my defines.

#define WOLFSSL_BASE64_ENCODE
#define THREADX
#define WOLFSSL_USER_IO
#define NO_SESSION_CACHE
#define NO_WOLFSSL_SERVER
#define FP_MAX_BITS 8192 //4096
#define USE_FAST_MATH
#define WOLFSSL_SMALL_STACK
#define TFM_TIMING_RESISTANT
#define NO_WRITEV
#define NO_ERROR_STRINGS
#define NO_WOLFSSL_DIR
#define NO_INLINE
#define HAVE_TIME_T_TYPE
#define HAVE_TM_TYPE
#define HAVE_VALIDATE_DATE
#define XVALIDATE_DATE(d, f, t) wolfssl_certificate_validate_Date((d), (f), (t))

//Used for wolfssl version 3.12.2
#define WOLFSSL_HAVE_MIN
#define WOLFSSL_HAVE_MAX
#define WOLFSSL_ALERT_COUNT_MAX 5
#define HAVE_AES_DECRYPT
#define HAVE_AES_ENCRYPT
#define HAVE_AES_CBC
#define WOLFSSL_STATIC_RSA
#define AES_MAX_KEY_SIZE 256

OS : ThreadX
SDK: Azure-iot-sdk "up to date"
TCP/IP: NetX
SSL: WolfSSL 3.12.2
Arm microprocessor: Renesas

Compiler complains about `FALL_THROUGH`

While compiling wolfMQTT for esp32-idf platform (https://github.com/espressif/esp-idf) I'm getting following warning:

[2/8] Building C object esp-idf/wolfmqtt/CMakeFiles/__idf_wolfmqtt.dir/__/__/3rd_party/wolfmqtt-1.4.0/src/mqtt_packet.c.obj
In file included from ../../../3rd_party/wolfssl-4.4.0/wolfssl/wolfcrypt/logging.h:33,
                 from ../../../3rd_party/wolfssl-4.4.0/wolfssl/ssl.h:35,
                 from ../../../3rd_party/wolfmqtt-1.4.0/wolfmqtt/mqtt_types.h:70,
                 from ../../../3rd_party/wolfmqtt-1.4.0/wolfmqtt/mqtt_packet.h:34,
                 from ../../../3rd_party/wolfmqtt-1.4.0/src/mqtt_packet.c:27:
../../../3rd_party/wolfmqtt-1.4.0/src/mqtt_packet.c: In function 'MqttPacket_Read':
../../../3rd_party/wolfssl-4.4.0/wolfssl/wolfcrypt/types.h:247:34: warning: attribute 'fallthrough' not preceding a case label or default label
             #define FALL_THROUGH __attribute__ ((fallthrough));
                                  ^~~~~~~~~~~~~
../../../3rd_party/wolfmqtt-1.4.0/src/mqtt_packet.c:1781:13: note: in expansion of macro 'FALL_THROUGH'
             FALL_THROUGH;
             ^~~~~~~~~~~~

It's issued cause int i is defined inside case block. If int i; is moved at the beginning of the function or FALL_THROUGH is moved outside the block this warning is gone.

-188 failure when verify aws iot core server on ats endpoint

I think this might be a problem of wolfSSL instead of wolfMQTT but here we have a complete example to reproduce.

Initially I found this problem on my platform where non-ats endpoint works perfect, when move to -ats endpoint I was not able to pass server certification verification and get error -188 from wolfSSL.

I see in your example you're also using non ats endpoint which is signed by VeriSign root ca. Could you please try to use -ats endpoint and trust Amazon Root or other roots for the reason of cross signed?

See this page https://docs.aws.amazon.com/iot/latest/developerguide/server-authentication.html?icmpid=docs_iot_console#server-authentication-certs

wolfmqtt/options.h is never included

When building wolfmqtt it generates and stores the configure options in options.h but the header is never included anywhere. Instead, the defines are passed along in the compile invocation command which causes the built library and the user code to have different sizes on the MqttClient struct due to ENABLE_MQTT_TLS not being defined.

You can work around this by including the header yourself before including any other library headers but I suspect the intention was for the library to handle it.

Edit: There seems to be something else going on. Even when including options.h manually I still have parts of the net structure cleared by the XMEMSET during initialization. Connect and context are both cleared while disconnect, read and write are untouched. It could be WOLFMQTT_DISCONNECT_CB which is defined when building the library but not when using it as it's missing from options.h.

run configure on linux error.

I clone wolfMQTT from github, then followed README:

./autogen.sh
./configure

it give me error:

configure: error: libwolfssl is required for wolfmqtt, .....

I try two methed:

  1. install wolfssl using apt-get
  2. build wolfssl and intall it, then run configure with option: --with-libwolfssl-prefix=/path/to/wolfssl/install

error still existed.

my linux version is : linuxmint 18.3 (it based on ubuntu 16.04, and I think it works same).

Thanks!

Non-blocking solution?

Is there any plan to support a non-blocking api in the future? For most applications, it is important to be able to publish and subscribe at the same time.

MQTT V5 - Last will topic should have properties

According to MQTT V5 specification a last will topic should have properties.
This is currently not implemented in wolfMQTT and should be added.
In my use case the MQTT server failed to parse my connect message due to this, so as a workaround I added a properties length field of 0 to the lwt.
wolfmqtt/src/mqtt_packet.c Line ~703

    /* Encode payload */
    tx_payload += MqttEncode_String(tx_payload, mc_connect->client_id);

    if (mc_connect->enable_lwt) {

        /* Workaround! Add property length field for lwt. Hardcoded to 0 props */
        tx_payload += MqttEncode_Vbi(tx_payload, 0);

        tx_payload += MqttEncode_String(tx_payload,
            mc_connect->lwt_msg->topic_name);
        tx_payload += MqttEncode_Data(tx_payload,
            mc_connect->lwt_msg->buffer, (word16)mc_connect->lwt_msg->total_len);
    }

WOLFMQTT_NONBLOCK - Multithreaded - Clarification

Hello,

The user manual lacks a lot of information on what WOLFMQTT_NONBLOCK does. Looking at the multithreading example:

#if defined(WOLFMQTT_MULTITHREAD) && !defined(WOLFMQTT_NONBLOCK)

The MQTTCtx structure is only available if NONBLOCK is not enabled?
Can you please provide more information on what NONBLOCK is doing?

Also, looking at example 5.3 in the user manual for MqttClient_Connect(...) it doesn't specify the broker IP anywhere. Please advise.

Also, MQTTCtx is not being recognized by the compiler? Do I have to include any other specific header file?
To call the int MqttClientNet_Init(MqttNet* net, MQTTCtx* mqttCtx) function, I would need to populate MQTTCtx structure.

Segmented writes do not work if len(topic) > TX buffer size

I don't know if this is by design, but "segmented" writes (fill buffer -> write -> fill buffer -> write) does not work if the header and topic length exceeds the TX buffer size when writing. In this crash I tried a TX buffer size of 16 when publishing to abcde/Sally-2.local/status:

frame #1: 0x00000001000a48d7 test `MqttEncode_Publish(tx_buf="����\x7f", tx_buf_len=16, publish=0x00007ffeefbfee28, use_cb='\0') at mqtt_packet.c:842
   839 	        if (payload_len > (tx_buf_len - (header_len + variable_len))) {
   840 	            payload_len = (tx_buf_len - (header_len + variable_len));
   841 	        }
-> 842 	        XMEMCPY(tx_payload, publish->buffer, payload_len);
   843 	    }
   844 	    publish->intBuf_pos = 0;
   845 	    publish->intBuf_len = payload_len;
(lldb) print payload_len
(int) $0 = -16
(lldb) print header_len
(int) $1 = 2
(lldb) print variable_len
(int) $2 = 30
(lldb) print tx_buf_len
(int) $3 = 16

If I increase the buffer size to 32 it works as expected.

Error when building on Visual Studio 2019

There is an error message shows when building on the Visual Studio 2019:

Error C1083 Cannot open include file: 'wolfmqtt/options.h': No such file or directory awsiot D:\Users\kusumy\Documents\Code\VStudio\wolfMQTT\wolfmqtt\mqtt_client.h 37

Need help ..

Some errors occured by using STM32F103ZET6+W5500

Recently, I wanna to port the wolfMQTT library to my board which is compoent by STM32F103ZET6 + W5500. And my develop environment is MDKV5.31.0.0. Here is my debugging phenomenon. And the MQTT server is Iot Core In Baidu.

When I used the wolfMQTTV0.8, Everything is OK! The message from USART is :
`
ip is :192.168.1.129
gw is :192.168.1.1
mac is :0.8.220.17.18.22
DHCP LEASED TIME : 7200 Sec.
MQTT Net Init: Success (0)
MQTT Init: Success (0)

1st DNS Reponsed
Translated asyfdev.iot.gz.baidubce.com to 14.215.189.33
MQTT Socket Connect: Success (0)
MQTT Connect: Success (0)
MQTT Connect Ack: Return Code 0, Session Present 0
MQTT Subscribe: Success (0)
Topic $iot/ForBooks/user/temperature, Qos 0, Return Code 0
MQTT Waiting for message...
MQTT Message: Topic $iot/ForBooks/user/temperature, Qos 0, Len 6
Payload (0 - 6): dasffd **// ** I send the message by MQTT.fx
MQTT Message: Done
Ping....
`

When I used the wolfMQTTV0.9 to V0.11 with the same code. The timeout error will be occured when send keep alive :
`=== W5500 NET CONF ===
ip is :192.168.1.129
gw is :192.168.1.1
mac is :0.8.220.17.18.22
DHCP LEASED TIME : 7200 Sec.
MQTT Net Init: Success (0)
MQTT Init: Success (0)

1st DNS Reponsed
Translated asyfdev.iot.gz.baidubce.com to 14.215.189.33
MQTT Socket Connect: Success (0)
MQTT Connect: Success (0)
MQTT Connect Ack: Return Code 0, Session Present 0
MQTT Subscribe: Success (0)
Topic $iot/ForBooks/user/temperature, Qos 0, Return Code 0
MQTT Waiting for message...
MQTT Message: Topic $iot/ForBooks/user/temperature, Qos 0, Len 6
Payload (0 - 6): dasffd
MQTT Message: Done
MQTT Ping Keep Alive Error: Error (Timeout) (-7) // I can receive messag, by timeout error occured!
`

When I used the wolfMQTTV0.12 to The lastest version with the same code. I can't communicat with MQTT.fx anymore. But From the debug message, we can see that stm32 can connect MQTT server OK, while it will be disconnected by some unkown errors. The debug message is:
`=== W5500 NET CONF ===
ip is :192.168.1.129
gw is :192.168.1.1
mac is :0.8.220.17.18.22
DHCP LEASED TIME : 7200 Sec.
MQTT Net Init: Success (0)
MQTT Init: Success (0)

1st DNS Reponsed
Translated asyfdev.iot.gz.baidubce.com to 14.215.190.76
MQTT Socket Connect: Success (0)
MQTT Connect: Success (0)
MQTT Connect Ack: Return Code 0, Session Present 0
MQTT Subscribe: Success (0)
Topic $iot/ForBooks/user/temperature, Qos 0, Return Code 0
MQTT Waiting for message...
# in this place, we send message by MQTT.fx,but can’t be received.
MQTT Message Wait: Error (Network) (-8)
`

my test file is :

MQTT_Temp.zip

mock MQTT broker

Is there a possibility in the development plans for the introduction into this project of the simplest internal mock MQTT broker, for which the transport level between tasks would be transmitted through buffers ?

AWS IoT over Port 443

Hi,
to communicate with AWS IoT over port 443 the ALPN ProtocolName "x-amzn-mqtt-ca" has to be provided in the client hello. wolfssl supports that:

char alpn_list[] = "x-amzn-mqtt-ca";
wolfSSL_UseALPN(client->tls.ssl, alpn_list, strlen(alpn_list), WOLFSSL_ALPN_CONTINUE_ON_MISMATCH);

But there is no callback to execute that code after wolfSSL_new() and beforewolfSSL_connect() in mqtt_socket.c -> MqttSocket_Connect(). Any suggestions how to accomplish that without modifying mqtt_socket.c?

Thanks!

Build fails with Clang and --enable-mqtt5

Tested with Clang 11.

src/mqtt_packet.c:499:25: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                buf_len - (buf - pbuf));
                ~~~~~~~~^~~~~~~~~~~~~~
src/mqtt_packet.c:554:33: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                        buf_len -(buf - pbuf));
                        ~~~~~~~~^~~~~~~~~~~~~
src/mqtt_packet.c:796:32: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                    rx_buf_len - (rx_payload - rx_buf));
                    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:805:43: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                               rx_buf_len - (rx_payload - rx_buf), props_len);
                               ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:975:28: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                rx_buf_len - (rx_payload - rx_buf));
                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:985:32: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                    rx_buf_len - (rx_payload - rx_buf), props_len);
                    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1125:32: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                    rx_buf_len - (rx_payload - rx_buf));
                    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1135:44: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                                rx_buf_len - (rx_payload - rx_buf), props_len);
                                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1265:32: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                    rx_buf_len - (rx_payload - rx_buf));
                    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1275:44: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                                rx_buf_len - (rx_payload - rx_buf), props_len);
                                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1398:36: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                        rx_buf_len - (rx_payload - rx_buf));
                        ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1408:44: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                                rx_buf_len - (rx_payload - rx_buf), props_len);
                                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1575:32: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                    rx_buf_len - (rx_payload - rx_buf));
                    ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1585:40: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                            rx_buf_len - (rx_payload - rx_buf), props_len);
                            ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1686:28: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                rx_buf_len - (rx_payload - rx_buf));
                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
src/mqtt_packet.c:1696:36: error: implicit conversion loses integer precision: 'long' to 'word32' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
                        rx_buf_len - (rx_payload - rx_buf), props_len);

Using MQTT v5 on Arduino

Hi,

We are using WolfMQTT as an Arduino library. This works great, except that we need to make a small manual adjustment to get MQTT v5 working. The following steps will reproduce the issue:

  • Run ./autogen.sh
  • Run ./configure with the --enable-mqtt5 flag and --disable-tls
  • Run wolfmqtt-arduino.sh in the IDE/ARDUINO folder
  • Move the resulting library to the Arduino libraries folder
  • Compile the Arduino project

This will result in a lot of compilation errors:

In file included from Arduino/libraries/wolfMQTT/mqtt_packet.c:28:0:
Arduino/libraries/wolfMQTT/wolfmqtt/mqtt_client.h:360:2: error: unknown type name 'MqttAuth'
  MqttAuth *auth);
  ^
Arduino/libraries/wolfMQTT/wolfmqtt/mqtt_client.h:369:14: error: unknown type name 'MqttProp'
 WOLFMQTT_API MqttProp* MqttClient_PropsAdd(
              ^
Arduino/libraries/wolfMQTT/wolfmqtt/mqtt_client.h:370:5: error: unknown type name 'MqttProp'
     MqttProp **head);

....

These errors are generated because the WOLFMQTT_V5 macro is not defined in mqtt_packet.h, which will result in missing definitions.

Possible solution:
Change:

/* Uncomment this to enable TLS support */
/* Make sure and include the wolfSSL library */
//#define ENABLE_MQTT_TLS

Into:
#include "options.h"

This solves our problem and other users who use TLS don't have to uncomment that line anymore.

CPPFLAGS used for C sources

When configuring and adding additional CFLAGS they do not get included in the build command. Instead, you need to add them to CPPFLAGS in order to adapt the build.

Compiling Examples

Hello,

I installed WolfSSL and WolfMQTT on my Ubuntu 18.06 LTS, however there is no instructions on how to get the examples compiled and running.
Can you please point me to any documentation pertaining compilation of examples? (Also, same for when I write my own client).

prateekkhatri@PC-10307:~/work/wolf/wolfMQTT/examples/mqttclient$ gcc mqttclient.c -o mqtt-test-wolf -lwolfmqtt In file included from mqttclient.c:29:0: mqttclient.h:25:10: fatal error: examples/mqttexample.h: No such file or directory #include "examples/mqttexample.h" ^~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.

Thanks,
Prateek

Infinite loop for certain buffer sizes

For some constellations of buffer size and payload size, the MQTT client seems not to send all the data.
This leads to infinite loops if QoS1 is used, since the client thinks it has sent all the data, but the server is not sending the ACK.
If QoS0 is set, the MQTT Client thinks it has sent the data, but the server is running into a timeout and it seems it did not reveive all data.

Example:
TX-Buffer size: 512
The buf_len of MqttSocket_WriteDo() is set to 512. MqttSocket_WriteDo() is called only once, but a few bytes (34 Bytes) are still missing. The state machine is not sending anymore, but is waiting for the Server ACK (since QoS is 1)

This might be related to #142

Environment: Microchip Harmony v2.6
OS: FreeRTOS
Defines:
#define WOLFSSL_BASE64_ENCODE
#define WOLFMQTT_CUSTOM_MALLOC
#define WOLFMQTT_MALLOC(s) pvPortMalloc((s))
#define WOLFMQTT_FREE(p) vPortFree((p))
#define ENABLE_MQTT_TLS
#define WOLFMQTT_NONBLOCK
#define MICROCHIP_MPLAB_HARMONY
#define MICROCHIP_TCPIP
#define MICROCHIP_PIC32
#define MICROCHIP_PIC32_RNG

Timeout ignored when TLS is active

Hi there,

MQTT version: 1.4

When TLS is active, the client-timeout is ignored. This can lead to infinite loops if the server is not sending the ACK for QoS1. (What happened, therefore this bug report)

static int MqttSocket_ReadDo(MqttClient *client, byte* buf, int buf_len,
    int timeout_ms)
{
    int rc;

#ifdef ENABLE_MQTT_TLS
    if (client->flags & MQTT_CLIENT_FLAG_IS_TLS) {
        client->tls.timeout_ms = timeout_ms; // <- it is set here, but never used!
        rc = wolfSSL_read(client->tls.ssl, (char*)buf, buf_len);
        if (rc < 0) {
        #ifdef WOLFMQTT_DEBUG_SOCKET
            int error = wolfSSL_get_error(client->tls.ssl, 0);
            if (error != WOLFSSL_ERROR_WANT_READ) {
                PRINTF("MqttSocket_Read: SSL Error=%d", error);
            }
        #endif

Environment: Microchip Harmony v2.6
Defines:
#define WOLFSSL_BASE64_ENCODE
#define WOLFMQTT_CUSTOM_MALLOC
#define WOLFMQTT_MALLOC(s) pvPortMalloc((s))
#define WOLFMQTT_FREE(p) vPortFree((p))
#define ENABLE_MQTT_TLS
#define WOLFMQTT_NONBLOCK
#define MICROCHIP_MPLAB_HARMONY
#define MICROCHIP_TCPIP
#define MICROCHIP_PIC32
#define MICROCHIP_PIC32_RNG

libtool unable to infer tagged configuration

I am trying to compile wolfMQTT on Ubuntu Wily. I can configure just fine but when I try to compile I get a libtool error:

(slightly edited for readbility)

libtool --silent --mode=compile @echo compiling Vendor/wolfMQTT/src/mqtt_client.c && gcc -c -m64 -pipe -std=gnu99 -g -fPIC -D_REENTRANT -DWOLFMQTT_NONBLOCK -DWOLFMQTT_DEBUG_CLIENT -o bin/mqtt_client.lo Vendor/wolfMQTT/src/mqtt_client.c
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'

This is supposed to be remedied with --tag=CC which seems to be present in Makefile.in but does not end up in the final makefile.

gcc --version
gcc (Ubuntu 5.2.1-23ubuntu1~15.10) 5.2.1 20151028

Harmony 3 TLS connection

Hi,
I’m using harmony 3 with the ethernet starter kit 2 (PIC32MZ795F512L) and have a working stack, console etc.
The mqtt connection works as expected using the unencrypted port 1883 and the default mqtt.eclipse.org broker, however when I try to create a encrypted connection on port 8883 I have the following error,

MQTT_NET_GLUE Info: Started Connect
WMQTT_NET_GLUE Info: Connected Successfully
WMQTT_NET_GLUE Info: Start TLS
WMQTT_NET_GLUE Error: Start Encryption, occurred in func: WMQTT_NETGlue_Connect, line: 300,

Debugging the program, inside net_pres.c the code returns false inside NET_PRES_SocketEncryptSocket() at,

if(pSkt->provObject->fpInit == 0 || pSkt->provObject->fpOpen == 0 || pSkt->provObject->fpIsInited == 0)
{ // cannot start negotiation
return false;
}

I suspect I haven’t setup the TLS correctly in wolfssl, but enabling TLS 1.3 support causes build errors with HKDF not being defined.

Should I be enabling TLS support in wolfssl or is mqtt doing this for me?

Building for Arduino does not work.

After following the README for flattening the files into an Arduino library and importing/including it with a minimal project, there is a build error.

Code is a bare minimum, with the library included. This is not expected to function, only to build to verify the library:

`
#include <mqttclient.h>
#include <mqttexample.h>
#include <mqttnet.h>
#include <wolfMQTT.h>

void setup() {
// put your setup code here, to run once:

}

void loop() {
// put your main code here, to run repeatedly:

}
`

However, the build/"verify" step produces the output with error listed below. The target is a simple Cortex M board, however the error is identical for any other ARM or AVR board.

/Applications/Arduino.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware /Applications/Arduino.app/Contents/Java/hardware -hardware /Users/xyz/Library/Arduino15/packages -hardware /Users/xyz/Documents/Arduino/hardware -tools /Applications/Arduino.app/Contents/Java/tools-builder -tools /Applications/Arduino.app/Contents/Java/hardware/tools/avr -tools /Users/xyz/Library/Arduino15/packages -built-in-libraries /Applications/Arduino.app/Contents/Java/libraries -libraries /Users/xyz/Documents/Arduino/libraries -fqbn=adafruit:samd:adafruit_feather_m0 -ide-version=10801 -build-path /var/folders/dy/nsmz0p8s06b0z0_rrfvqtqz40000gn/T/arduino_build_239243 -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.openocd.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/openocd/0.9.0-arduino -prefs=runtime.tools.arm-none-eabi-gcc.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1 -prefs=runtime.tools.bossac.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/bossac/1.6.1-arduino -prefs=runtime.tools.CMSIS.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel -verbose /Users/xyz/Documents/Arduino/sketches/wolfmqtt_test/wolfmqtt_test.ino /Applications/Arduino.app/Contents/Java/arduino-builder -compile -logger=machine -hardware /Applications/Arduino.app/Contents/Java/hardware -hardware /Users/xyz/Library/Arduino15/packages -hardware /Users/xyz/Documents/Arduino/hardware -tools /Applications/Arduino.app/Contents/Java/tools-builder -tools /Applications/Arduino.app/Contents/Java/hardware/tools/avr -tools /Users/xyz/Library/Arduino15/packages -built-in-libraries /Applications/Arduino.app/Contents/Java/libraries -libraries /Users/xyz/Documents/Arduino/libraries -fqbn=adafruit:samd:adafruit_feather_m0 -ide-version=10801 -build-path /var/folders/dy/nsmz0p8s06b0z0_rrfvqtqz40000gn/T/arduino_build_239243 -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.openocd.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/openocd/0.9.0-arduino -prefs=runtime.tools.arm-none-eabi-gcc.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1 -prefs=runtime.tools.bossac.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/bossac/1.6.1-arduino -prefs=runtime.tools.CMSIS.path=/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel -verbose /Users/xyz/Documents/Arduino/sketches/wolfmqtt_test/wolfmqtt_test.ino Using board 'adafruit_feather_m0' from platform in folder: /Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13 Using core 'arduino' from platform in folder: /Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13 Build options changed, rebuilding all Detecting libraries used... "/Users/xyz/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -mcpu=cortex-m0plus -mthumb -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -fno-threadsafe-statics -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -w -x c++ -E -CC -DF_CPU=48000000L -DARDUINO=10801 -DARDUINO_SAMD_FEATHER_M0 -DARDUINO_ARCH_SAMD -DARDUINO_SAMD_ZERO -D__SAMD21G18A__ -DUSB_VID=0x239A -DUSB_PID=0x800B -DUSBCON '-DUSB_MANUFACTURER="Adafruit"' '-DUSB_PRODUCT="Feather M0"' "-I/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel/CMSIS/Include/" "-I/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel/Device/ATMEL/" "-I/Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13/cores/arduino" "-I/Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13/variants/arduino_zero" "/var/folders/dy/nsmz0p8s06b0z0_rrfvqtqz40000gn/T/arduino_build_239243/sketch/wolfmqtt_test.ino.cpp" -o "/dev/null" "/Users/xyz/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -mcpu=cortex-m0plus -mthumb -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -fno-threadsafe-statics -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -w -x c++ -E -CC -DF_CPU=48000000L -DARDUINO=10801 -DARDUINO_SAMD_FEATHER_M0 -DARDUINO_ARCH_SAMD -DARDUINO_SAMD_ZERO -D__SAMD21G18A__ -DUSB_VID=0x239A -DUSB_PID=0x800B -DUSBCON '-DUSB_MANUFACTURER="Adafruit"' '-DUSB_PRODUCT="Feather M0"' "-I/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel/CMSIS/Include/" "-I/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel/Device/ATMEL/" "-I/Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13/cores/arduino" "-I/Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13/variants/arduino_zero" "-I/Users/xyz/Documents/Arduino/libraries/wolfmqtt" "/var/folders/dy/nsmz0p8s06b0z0_rrfvqtqz40000gn/T/arduino_build_239243/sketch/wolfmqtt_test.ino.cpp" -o "/dev/null" "/Users/xyz/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -mcpu=cortex-m0plus -mthumb -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -fno-threadsafe-statics -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -w -x c++ -E -CC -DF_CPU=48000000L -DARDUINO=10801 -DARDUINO_SAMD_FEATHER_M0 -DARDUINO_ARCH_SAMD -DARDUINO_SAMD_ZERO -D__SAMD21G18A__ -DUSB_VID=0x239A -DUSB_PID=0x800B -DUSBCON '-DUSB_MANUFACTURER="Adafruit"' '-DUSB_PRODUCT="Feather M0"' "-I/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel/CMSIS/Include/" "-I/Users/xyz/Library/Arduino15/packages/arduino/tools/CMSIS/4.0.0-atmel/Device/ATMEL/" "-I/Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13/cores/arduino" "-I/Users/xyz/Library/Arduino15/packages/adafruit/hardware/samd/1.0.13/variants/arduino_zero" "-I/Users/xyz/Documents/Arduino/libraries/wolfmqtt" "/var/folders/dy/nsmz0p8s06b0z0_rrfvqtqz40000gn/T/arduino_build_239243/sketch/wolfmqtt_test.ino.cpp" -o "/var/folders/dy/nsmz0p8s06b0z0_rrfvqtqz40000gn/T/arduino_build_239243/preproc/ctags_target_for_gcc_minus_e.cpp" In file included from /Users/xyz/Documents/Arduino/sketches/wolfmqtt_test/wolfmqtt_test.ino:1:0: /Users/xyz/Documents/Arduino/libraries/wolfmqtt/mqttclient.h:25:34: fatal error: examples/mqttexample.h: No such file or directory #include "examples/mqttexample.h" ^ compilation terminated. Using library wolfmqtt in folder: /Users/xyz/Documents/Arduino/libraries/wolfmqtt (legacy) exit status 1 Error compiling for board Adafruit Feather M0 (Native USB Port).

Ping Message not trigged

Hi there,

I was running your mqttsimple example with the mosquitto broker.

I realized the Ping request on the client was never triggered.

I investigated the issue and examined the problem to be the mqtt_net_read function. In my opinion the socket timeout is never triggered, because it should be a SO_RCVTIMEO timeout:

setsockopt(*pSockFd, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv, sizeof(tv));

Cheers,
Marc

Multithread test with qos 1 -2 failing

The multithread test is failing with QoS 1 and 2.

./configure --enable-mt
make
./examples/multithread/multithread -h localhost -T -C 5000 -q 1
MQTT Client: QoS 1, Use TLS 0
Use "Ctrl+c" to exit.
MQTT Net Init: Success (0)
MQTT Init: Success (0)
NetConnect: Host localhost, Port 1883, Timeout 5000 ms, Use TLS 0
MQTT Socket Connect: Success (0)
MQTT Connect: Proto (v3.1.1), Success (0)
MQTT Connect Ack: Return Code 0, Session Present 0
MQTT Subscribe: Success (0)
  Topic wolfMQTT/example/testTopic_3F34910A, Qos 1, Return Code 1
MQTT Waiting for message...
MQTT Message: Topic wolfMQTT/example/testTopic_3F34910A, Qos 1, Id 1, Len 6
Payload (0 - 6): test02
MQTT Message: Done
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, Success (0)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, Error (Packet Type Mismatch) (-4)
MQTT Message Wait Error: Error (Packet Type Mismatch) (-4)
Sending ping keep-alive
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, Error (Packet Type Mismatch) (-4)
Network Error Callback: Error (Timeout) (error -7)
MQTT Ping Keep Alive Error: Error (Timeout) (-7)
Network Error Callback: Error (Timeout) (error -7)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, Error (Timeout) (-7)
^CReceived SIGINT
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, STDIN Wake (-102)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, STDIN Wake (-102)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, STDIN Wake (-102)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, STDIN Wake (-102)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, STDIN Wake (-102)
Network Error Callback: Error (Network) (error -8)
MQTT Publish: Topic wolfMQTT/example/testTopic_3F34910A, Error (Network) (-8)
NetRead: Error 32
Network Error Callback: Error (Network) (error -8)
MQTT Unsubscribe: Error (Network) (-8)

MqttNet context overwritten in MqttConnect corner case circumstance

Broker: EMQTTD
Application OS: Zephyr Project RTOS
TLS Stack: WolfSSL Zephyr port (although I will note we have built-in MqttTls disabled. We implement the TLS setup and connect in our MqttNet callbacks so that we can better access the TLS context for logging and control of the ciphersuites)
wolfMQTT configuration: No multithreading, TLS disabled

Hello, I've noticed a peculiar behavior with MqttClient_WaitType() in a very specific circumstance that I would like some clarification on. The scenario I'm experiencing is as follows:

Problem Scenario:

  1. Client connects successfully with clean session and disconnects ungracefully (due to device poweroff or segfault, etc)
  2. Before keep alive expires on the broker side, a QoS 1 message is published to a topic in the client's active subscriptions. Since the broker receives no PUBACK from the client, it saves the message.
  3. Client is manually restarted and attempts clean session connection. (Problem occurs regardless of whether keep alive has expired on broker side or not).
  4. Broker receives Connect packet, and publishes the QoS 1 message before sending Connack. It does send Connack after the publish, however, the device is unable to receive it, for the following reason.
  5. The client's WolfMqtt stack is in MqttClient_WaitType, expecting a CONNACK packet but receives a publish. As best as I can figure, since the packet_obj passed in was a connect ack, processing the publish overruns the packet_obj and overwrites the memory in my MqttNet context pointer.
  6. Further calls to our NetRead callback return WOLFSSL_FAILURE due to the mangled context, which propagate back to failed MqttConnect.

I know for sure that the memory is being overwritten because GDB shows in the stack frame of MqttDecode_String the p_str argument has the address of my socket file descriptor. What I'm seeking guidance about is whether this scenario is caused by a problem with the broker (ie, it shouldn't send the Publish before the Connack), if this scenario is always possible and is a bug in wolfMQTT, or if the stack in the Zephyr RTOS is simply being mishandled.

As noted above, we are not using WolfSSL through the built in MqttTls support. We handle TLS context around our socket in the Net callbacks and have had no issues with the TLS or TCP layers thus far.

The struct passed up to the callbacks through MqttNet context is like so:

struct tls_ctx tls {  
    int sockfd;  
    WOLFSSL_CTX *ssl_ctx;  
    WOLFSSL *ssl;  
};

If I store this struct in global memory and allow the Net callbacks to access it that way, the overwrite problem does not happen.

Thank you in advance for any insight you can provide. I will happily elaborate or provide further code snippets if needed

Parts of the payload is sent twice for MQTT buffer length < data-length

Hi there,

If the tx-buffer length for the MQTT client is smaller then the data sent, the function MqttClient_Publish_WritePayload() will send the start of the payload twice.
Once, since the payload is set in MqttEncode_Publish for the remainder of the tx-buffer.
Second, when MqttClient_Publish_WritePayload is called, since it does not take into account the values of intBuf_pos and intBuf_len.

I could fix it more or less by using this:

---
 third_party/tcpip/wolfmqtt/src/mqtt_client.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/third_party/tcpip/wolfmqtt/src/mqtt_client.c b/third_party/tcpip/wolfmqtt/src/mqtt_client.c
index e8c3324a..8458989b 100644
--- a/third_party/tcpip/wolfmqtt/src/mqtt_client.c
+++ b/third_party/tcpip/wolfmqtt/src/mqtt_client.c
@@ -1219,18 +1219,14 @@ static int MqttClient_Publish_WritePayload(MqttClient *client,
         } while (publish->buffer_pos < publish->total_len);
     }
     else if (publish->buffer_pos < publish->total_len) {
-        if (publish->buffer_pos > 0) {
-            XMEMCPY(client->tx_buf, publish->buffer,
-                client->write.len);
-        }
+//        if (publish->buffer_pos > 0) {
+//            XMEMCPY(client->tx_buf, publish->buffer,
+//                client->write.len);
+//        }
 
         /* Send packet and payload */
         do {
-            rc = MqttPacket_Write(client, client->tx_buf,
-                    client->write.len);
-            if (rc < 0) {
-                return rc;
-            }
+
 
             publish->intBuf_pos += publish->intBuf_len;
             publish->intBuf_len = 0;
@@ -1249,6 +1245,12 @@ static int MqttClient_Publish_WritePayload(MqttClient *client,
             publish->intBuf_len = client->write.len;
             XMEMCPY(client->tx_buf, &publish->buffer[publish->intBuf_pos],
                 client->write.len);
+            
+            rc = MqttPacket_Write(client, client->tx_buf,
+                    client->write.len);
+            if (rc < 0) {
+                return rc;
+            }
 
         #ifdef WOLFMQTT_NONBLOCK
             return MQTT_CODE_CONTINUE;
-- 

But I am not sure if this is the way to go...

Environment: Microchip Harmony v2.6
OS: FreeRTOS
Defines:
#define WOLFSSL_BASE64_ENCODE
#define WOLFMQTT_CUSTOM_MALLOC
#define WOLFMQTT_MALLOC(s) pvPortMalloc((s))
#define WOLFMQTT_FREE(p) vPortFree((p))
#define ENABLE_MQTT_TLS
#define WOLFMQTT_NONBLOCK
#define MICROCHIP_MPLAB_HARMONY
#define MICROCHIP_TCPIP
#define MICROCHIP_PIC32
#define MICROCHIP_PIC32_RNG

MQTT_DATA_TYPE_BINARY data len encoded twice

Function MqttEncode_Props must change like below:

case MQTT_DATA_TYPE_BINARY:
{
#if 0
/* Binary type is a two byte integer "length"
followed by that number of bytes */
tmp = MqttEncode_Num(buf, cur_prop->data_bin.len);
rc += tmp;
if (buf != NULL) {
buf += tmp;
}
#endif

            tmp = MqttEncode_Data(buf, (const byte*)cur_prop->data_bin.data,
                    cur_prop->data_bin.len);
            rc += tmp;
            if (buf != NULL) {
                buf += tmp;
            }
            break;
        }

windows-mingw build problems

Thank you anyway very much for the library, we are starting to use it on esp8266 devices and linux machines for the mTask system and it's working promisingly well there. However, when trying to port the client to windows I encountered some problems:

When I try to cross-compile wolfMQTT for windows on my linux box I a mingw environment encounter several problems. I've also tried this on a native mingw windows system and have the same issues.

./autogen.sh
./configure --disable-tls --host=x86_64-pc-mingw32 CC=x86_64-w64-mingw32-gcc
make
  • When I disable tls (./configure --disable-tls) it still tries to include wolfssl libraries. This is because the ENABLE_MQTT_TLS definition is set even in mingw environments in vs_types.h. I thought vs_types.h was only required for visual studio. If I remove the definition from vs_types.h it works.

  • Then I proceed and get several attribute errors:

    src/mqtt_packet.c:3404:1: error: visibility attribute not supported in this configuration; ignored [-Werror=attributes]
    

    They can be turned into warnings by adding -Wno-attributes to the CFLAGS.

  • Then I proceed to compile and encounter the following error:

make
...
  CC       src/libwolfmqtt_la-mqtt_client.lo
  CC       src/libwolfmqtt_la-mqtt_packet.lo
examples/mqttnet.c: In function ‘NetWrite’:
examples/mqttnet.c:814:26: error: comparison is always false due to limited range of
data type [-Werror=type-limits]
             if (so_error == EWOULDBLOCK || so_error == EAGAIN) {
                          ^~
examples/mqttnet.c: In function ‘NetRead_ex’:
examples/mqttnet.c:962:26: error: comparison is always false due to limited range of
data type [-Werror=type-limits]
             if (so_error == EWOULDBLOCK || so_error == EAGAIN) {
                          ^~
cc1: all warnings being treated as errors
  CC       src/libwolfmqtt_la-mqtt_socket.lo

TLDR:

  • What is the meaning of vs_types.h and is it required to modify it in cross-compile mingw environments as well?
  • What do the attributes do and why are they not supported in cross-compile mingw environments?
  • I found some errors in the mqttnet.c example.

Configure does not include wolfSSL options header

The test program for the wolfssl detection does not include options.h which causes configure to use incorrect options. This usually ends up in a failure when cross compiling.

The patch is small but the test programs never finish so I am unable to submit a proper PR.

diff --git a/m4/have_wolfssl.m4 b/m4/have_wolfssl.m4
index fbd398d..5be9de6 100644
--- a/m4/have_wolfssl.m4
+++ b/m4/have_wolfssl.m4
@@ -12,6 +12,10 @@ AC_DEFUN([_TAO_SEARCH_LIBWOLFSSL],[

   AC_LIB_HAVE_LINKFLAGS(wolfssl,,
   [
+    #if !defined(WOLFSSL_USER_SETTINGS) && !defined(USE_WINDOWS_API)
+        #include <wolfssl/options.h>
+    #endif
+
     #include <wolfssl/ssl.h>
   ],[
     wolfSSL_Init();

Originally submitted as wolfSSL/wolfssl#1568

Big Endian in mqtt_types.h

Hey,

Just wondering why Big Endian isn't allowed (via the check in mqtt_types.h)? I'm using a few MIPS Big Endian devices and they work fine with the check commented out. ?

does it support to other MQ server such as activeMQ, rabbitMq

I am currently working on some async projects test case, and I have a lot of client need to do stress/integration testing. Due to different client has different mq server such as ActiveMQ, weblogic MQ, rabbitMq and so on. I am wondering is wolfMQTT can act as a client to do push pull, pub sub to any MQ server?

Publish using callback does not work with non-blocking mode.

The publish callback is used with MqttClient_Publish_ex and it currently uses MQTT_CODE_CONTINUE to indicate that the callback should process another block. The problem is that MQTT_CODE_CONTINUE is the return value from the non-block read / write to indicate the I/O should be called again. A new return code is needed to specify the condition that the callback should be executed again.

Reference: https://www.wolfssl.com/forums/topic1634-difficulty-using-mqttclientpublishex-with-pic32-harmony-300.html

Automatic connect function

Can you add automatic connect function? thanks.
For instance, When the broker restarts, ping/pong test cannot auto connect to the broker server.

like as:
Recently, I learned about paho. MQTT. C, and found the function as:
void connectionLost(void* context, char* cause)
url:
https://github.com/eclipse/paho.mqtt.c/blob/master/src/samples/paho_c_pub.c

so, Maybe the following function names are more appropriate:
typedef void (*lmqtt_client_on_connect_lost)(void *, lmqtt_connect_t *, int);

disconnect: Disconnect actively by itself
connect_lost: Passive disconnect.

Is it possible to specify physical interface for MQTT to use?

We are planning to have different interfaces on our board and one of the interface would have internet connectivity.
Is it possible to specify what physical interface to use while creating the client and connecting? I couldn't explicitly find this in the documentation.

Failure to build with gcc-7

while testing on debian Sid:
gcc version 7.2.0 (Debian 7.2.0-1)

make reports several implicit switch/case fall through, and treats them as errors because -Werror=implicit-fallthrough=

Publish triggers reception callback without context

If data is received when publishing a topic before you have received the publish ACK the message callback will be called but it will no longer contain the MqttClient context:

#5  0x00005555555b4f6a in Service::HandleMqttMessage (client=0x5555558ecda8, msg=0x5555558ece08, msg_new=1 '\001', msg_done=1 '\001') at src/MqttCloudService.cpp:31
^^ This is a callback for a subscribed topic, not an ack for the topic I just published.

#6  0x00005555555d0cb7 in MqttClient_HandlePayload (client=0x5555558ecda8, msg=0x5555558ece08, timeout_ms=1000, p_decode=0x0, packet_id=0x7fffffffd44a) at ../../Vendor/wolfMQTT/src/mqtt_client.c:79
#7  0x00005555555d118d in MqttClient_WaitType (client=0x5555558ecda8, msg=0x5555558ece08, timeout_ms=1000, wait_type=4 '\004', wait_packet_id=2, p_decode=0x0)
    at ../../Vendor/wolfMQTT/src/mqtt_client.c:290
#8  0x00005555555d15ce in MqttClient_Publish (client=0x5555558ecda8, publish=0x7fffffffd4e0) at ../../Vendor/wolfMQTT/src/mqtt_client.c:475
#9  0x00005555555b6653 in Service::MqttCloudService::Publish (this=0x5555558ecd20, data=0x7fffffffd760 "\n\n\b\004\025\022\002\310B\030\244\002\022\t\b\271\242\226\324\005\020\325\005", len=23, 

(gdb) print client->ctx
$3 = (void *) 0x0

For me this issue is twofold. Since the context is missing you can't use it to double dispatch into a C++ object. The other part is, how do I prevent this from happening to begin with? I can try to do a message read before publish but there's always the risk of the server pushing data to the client between the send request and the data arriving at the server. I have a feeling I'm using the library incorrectly when I'm not using the state machine from the examples.

Using TLS without wolfSSL

I am trying a setup where I use OpenSSL when building on the PC and SSL enabled sockets on our modem chip when building for the target device. This seems to work fine and allows me to skip much of the SSL/TLS handling in the MCU, thus freeing up resources.

Now I want to have the option to connect to TLS- and non-TLS servers, but the use_tls flag is never passed to the socket connect callback so there's no way to determine what type of connection to use. Is there a better way to use TLS without using wolfSSL?

Build on alpine linux Docker container fails at ./configure step

Using the Dockerfile below:

FROM alpine:latest AS builder
ADD https://github.com/wolfSSL/wolfssl/archive/v4.3.0-stable.tar.gz /opt/
ADD https://github.com/wolfSSL/wolfMQTT/archive/v1.4.tar.gz /opt/
RUN apk update && apk  --no-cache add ca-certificates tar bash libtool autoconf automake build-base

# Create appuser.
RUN adduser -D -g '' appuser
RUN mkdir /opt/wolfssl && tar -xzf /opt/v4.3.0-stable.tar.gz -C /opt/wolfssl
WORKDIR /opt/wolfssl/wolfssl-4.3.0-stable
RUN ./autogen.sh
RUN ./configure
RUN make && make install
RUN mkdir /opt/wolfmqtt && tar -xzf /opt/v1.4.tar.gz -C /opt/wolfmqtt
WORKDIR /opt/wolfmqtt/wolfMQTT-1.4
RUN ./autogen.sh
RUN ./configure
RUN make && make install

wolfSSL builds fine, but when Docker gets to the ./configure step for wolfMQTT, it fails with the error:

./configure: line 3: syntax error: unterminated quoted string

Changing #! /bin/sh in wolfMQTT's ./configure to #! /bin/bash fixes the problem, but I don't think this should be necessary since wolfSSL already configures properly.

As a workaround, I've added the line

RUN mv /bin/sh /bin/sh.bak && ln -s /bin/bash /bin/sh

prior to running the wolfMQTT build process.

build with mingw error

$ make
make  all-am
make[1]: Entering directory `/d/vs-dev/wolfmqtt-0.4'
  CC     src/src_libwolfmqtt_la-mqtt_client.lo
  CC     src/src_libwolfmqtt_la-mqtt_packet.lo
  CC     src/src_libwolfmqtt_la-mqtt_socket.lo
  CCLD   src/libwolfmqtt.la
  CC     examples/mqttclient/mqttclient.o
examples/mqttclient/mqttclient.c:490:14: warning: no previous prototype for 'CtrlHandler' [-Wmissing-prototypes]
         BOOL CtrlHandler(DWORD fdwCtrlType)
              ^
examples/mqttclient/mqttclient.c: In function 'main':
examples/mqttclient/mqttclient.c:519:13: warning: format '%d' expects argument of type 'int', but argument 2 has type 'DWORD' [-Wformat=]
             printf("Error setting Ctrl Handler! Error %d\n", GetLastError());
             ^
  CC     examples/mqttnet.o
examples/mqttnet.c: In function 'NetConnect':
examples/mqttnet.c:142:5: warning: implicit declaration of function 'getaddrinfo' [-Wimplicit-function-declaration]
     rc = getaddrinfo(host, NULL, &hints, &result);
     ^
examples/mqttnet.c:142:5: warning: nested extern declaration of 'getaddrinfo' [-Wnested-externs]
examples/mqttnet.c:165:9: warning: implicit declaration of function 'freeaddrinfo' [-Wimplicit-function-declaration]
         freeaddrinfo(result);
         ^
examples/mqttnet.c:165:9: warning: nested extern declaration of 'freeaddrinfo' [-Wnested-externs]
examples/mqttnet.c:174:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
         if (sock->fd != -1) {
                      ^
examples/mqttnet.c: In function 'NetWrite':
examples/mqttnet.c:227:5: warning: pointer targets in passing argument 2 of 'send' differ in signedness [-Wpointer-sign]
     rc = (int)send(sock->fd, buf, (size_t)buf_len, 0);
     ^
In file included from d:/libs/include/wolfssl/wolfcrypt/wc_port.h:42:0,
                 from d:/libs/include/wolfssl/wolfcrypt/types.h:27,
                 from d:/libs/include/wolfssl/wolfcrypt/error-crypt.h:26,
                 from ./wolfmqtt/mqtt_socket.h:41,
                 from ./wolfmqtt/mqtt_packet.h:35,
                 from ./wolfmqtt/mqtt_client.h:35,
                 from examples/mqttnet.c:27:
c:\mingw\include\winsock2.h:549:32: note: expected 'const char *' but argument is of type 'const unsigned char *'
 WINSOCK_API_LINKAGE int PASCAL send(SOCKET,const char*,int,int);
                                ^
examples/mqttnet.c: In function 'NetRead':
examples/mqttnet.c:276:32: warning: pointer targets in passing argument 2 of 'recv' differ in signedness [-Wpointer-sign]
                                0);
                                ^
In file included from d:/libs/include/wolfssl/wolfcrypt/wc_port.h:42:0,
                 from d:/libs/include/wolfssl/wolfcrypt/types.h:27,
                 from d:/libs/include/wolfssl/wolfcrypt/error-crypt.h:26,
                 from ./wolfmqtt/mqtt_socket.h:41,
                 from ./wolfmqtt/mqtt_packet.h:35,
                 from ./wolfmqtt/mqtt_client.h:35,
                 from examples/mqttnet.c:27:
c:\mingw\include\winsock2.h:547:32: note: expected 'char *' but argument is of type 'unsigned char *'
 WINSOCK_API_LINKAGE int PASCAL recv(SOCKET,char*,int,int);
                                ^
examples/mqttnet.c: In function 'NetDisconnect':
examples/mqttnet.c:317:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
         if (sock->fd != -1) {
                      ^
  CCLD   examples/mqttclient/mqttclient.exe
examples/mqttnet.o:mqttnet.c:(.text+0x44d): undefined reference to `getaddrinfo'
examples/mqttnet.o:mqttnet.c:(.text+0x47f): undefined reference to `freeaddrinfo'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [examples/mqttclient/mqttclient.exe] Error 1
make[1]: Leaving directory `/d/vs-dev/wolfmqtt-0.4'
make: *** [all] Error 2

RX Bug with large MQTT publish messages

Hi,
When a large publish message is received (on several TCP packet), and not all TCP packets are yet received (less than the size of the MQTT client RX buffer), the library will drop out the first packet, and try to decode the 2nd one.
This can be solved by adding a '=' line 272 of file mqtt_socket.c :

    /* handle return code */
    if (rc >**=** 0) {
        /* return length read and reset position */
        rc = client->read.pos;
        client->read.pos = 0;
    }

Other way, the library is working very well, thanks guys for it.
Bastien Laguionie

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.