eclipse/paho.mqtt-sn.embedded-c

Paho C MQTT-SN gateway and libraries for embedded systems. Paho is an Eclipse IoT project.

Eclipse Paho MQTT-SN C/C++ client for Embedded platforms

This repository contains the source code for the Eclipse Paho MQTT-SN C/C++ client library for Embedded platorms.

It is dual licensed under the EPL and EDL (see about.html and notice.html for more details). You can choose which of these licenses you want to use the code under. The EDL allows you to embed the code into your application, and distribute your application in binary or source form without contributing any of your code, or any changes you make back to Paho. See the EDL for the exact conditions.

There are three sub-projects:

1. MQTTSNPacket - simple de/serialization of MQTT-SN packets, plus helper functions
2. MQTTGateway - MQTT-SN transparent/aggregating gateway - connects MQTT-SN clients with an MQTT server. See the README within the project for more information.
3. MQTTSNClient - high(er) level C++ client (not yet complete)

The MQTTSNPacket directory contains the lowest level C library with the smallest requirements. This supplies simple serialization and deserialization routines. They serve as a base for the higher level libraries, but can also be used on their own. It is mainly up to you to write and read to and from the network.

The MQTTSNGateway directory contains an MQTT-SN to MQTT transparent/aggregating gateway (see the MQTT-SN specification for a description of that.) It can be used to connect the MQTT-SN client to an MQTT server.

The MQTTSNClient directory contains the next level C++ library. This is intended to mirror the way the MQTTClient works in the Paho embedded MQTT project, but it's not yet complete.

Build requirements / compilation

CMake builds have been introduced, along with Travis-CI configuration for automated build & testing.

The travis-build.sh file has the full build and test sequence for Linux.

Usage and API

See the samples directories for examples of intended use. Doxygen config files are available in the doc directory.

Runtime tracing

Reporting bugs

This project uses GitHub Issues here: github.com/eclipse/paho.mqtt-sn.embedded-c/issues to track ongoing development and issues.

More information

Discussion of the Paho clients takes place on the Eclipse Mattermost Paho channel and the Eclipse paho-dev mailing list.

General questions about the MQTT protocol are discussed in the MQTT Google Group.

More information is available via the MQTT community.

paho.mqtt-sn.embedded-c's Issues

MQTTSN-Gateway gets stuck at 100% CPU intermittently.

Ok, I'll fully admit I have no idea how to reproduce this reliably, I can only say it will always happen to me within a day or two.

I'm putting this here as a marker in the hope maybe something will be spotted or if someone else sees something.

Version: 64b4f7c (latest as of this writing)
Platform: Raspberry PI running Ubuntu
Network: XBee Series 2 over USB FTDI adapter.

Symptom: MQTTSN-Gateway process pegs CPU at basically 97-100% all of the time. Nothing else much running on the box.
Reproduction: This happens when it runs for a day or so. The system is relatively quiet; there is a publish every 5-10 seconds, otherwise not much happening. Usually only one client, which holds open a connection.

Config files should be a command line argument, not hard coded

Clarify usage of MulticastPort and GatewayPort

Reuse of the ::unicast function within ::broadcast in SensorNetwork.cpp like this:

int UDPPort::broadcast(const uint8_t* buf, uint32_t length)
{
return unicast(buf, length, &_grpAddr);
}

means that multicast packets (specifically, ADVERTISE) are actually being sent via the gateway port (:10000 in the default config) because the unicast socket descriptor is being used.

Is this intentional ?

MQTT to MQTT-SN Gateway functionality

Hi,

First of all, thank you for your hard work on this amazing project.

We have successfully used it to translate MQTT-SN messages to MQTT ones with much success. However, we are having troubles figuring out if we could use this project to translate regular MQTT messages sent by a VerneMQ broker to MQTT-SN messages so we could send information back to our low-powered devices.

Does this project present such functionality?

MQTTSN Gateway -- First publish from broker is ignored.

Gateway v0.9.0 (the pull request)

Look at the following log. This behaviour is consistent. Only look at "AnotherClientID". We are publishing the values '0' and '1' (hex 30 and 31) on topic "test2/pin/12". We send "1" from the broker, the gateway sends "1". We send "0", the gateway sends "1" again. We send "0" again, the gateway sends "0". After the first publish this will be consistent; the first publish will send the previous value, the next publish will send the updated value. It is easy to see as the value send is the last byte in every publish (broker->gateway or gateway->end)

20161012 210849.798   PUBLISH     0000  <---  AnotherClientID                     30 0F 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 32 31
     PacketHandleTask gets PUBLISH  0000 from the broker.

===> Send:     7e 00 16 10 25 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  08 0c 00 00 03 00 00 31   checksum   ae
 7e
===> Recv:     00 07 8b 25 4a 81 00 00 00 84    checksum ok
20161012 210849.889   PUBLISH     0000  --->  AnotherClientID                     0C 00 00 03 00 00 31
 7e
===> Recv:     00 14 90 00 13 a2 00 40 a6 92 b1 8b 00 01 08 0c 00 00 02 00 00 36 b9    checksum ok

20161012 210854.841   PUBLISH     0000  <---  SomeClientID                        0C 00 00 02 00 00 36
     PacketHandleTask gets PUBLISH  0000 from the client.
20161012 210854.842   PUBLISH     0000  --->  SomeClientID                        30 15 00 12 6D 71 74 74 73 6E 74 65 73 74 2F 43 6F 75 6E 74 65 72 36

20161012 210859.449   PUBLISH     0000  <---  AnotherClientID                     30 0F 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 32 30
     PacketHandleTask gets PUBLISH  0000 from the broker.

===> Send:     7e 00 16 10 26 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  08 0c 00 00 03 00 00 31   checksum   ad
 7e
===> Recv:     00 07 8b 26 4a 81 04 00 00 7f    checksum ok
20161012 210859.576   PUBLISH     0000  --->  AnotherClientID                     0C 00 00 03 00 00 31

20161012 210859.877   PUBLISH     0000  <---  AnotherClientID                     30 0F 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 32 30
     PacketHandleTask gets PUBLISH  0000 from the broker.

===> Send:     7e 00 16 10 27 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  08 0c 00 00 03 00 00 30   checksum   ad
 7e
===> Recv:     00 07 8b 27 4a 81 00 00 00 82    checksum ok
20161012 210900.092   PUBLISH     0000  --->  AnotherClientID                     0C 00 00 03 00 00 30

Known bug of MQTT-SNGateway's Topic

Topic does not support single level wildcard more than one level.
e.g. "+/tennis/+" , "+/tennis/#"

MQTT-SN Gateway crash by segfault

Hi all,
I use the MQTT-SN Client from this version"https://github.com/ty4tw/MQTT-SN"
And there is a segfault when the Client send the CONNECT request to Gateway(Look at the following log)

***************************************************************************
 * MQTT-SN Transparent Gateway
 * Part of Project Paho in Eclipse
 * (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/)
 *
 * Author : Tomoaki YAMAGUCHI
 * Version: 1.1.0
 ***************************************************************************

20170517 082652.806 PahoGateway-01 has been started.

ConfigFile: ./gateway.conf
 SensorN/W:  API mode 2, Baudrate 9600, SerialDevice /dev/ttyUSB1
 Broker:     localhost : 1883, 8883
 RootCApath: (null)
 RootCAfile: (null)
 CertKey:    (null)
 PrivateKey: (null)

20170517 082658.053   SEARCHGW          <---  Client                              01 00
20170517 082658.054   GWINFO            --->  Clients                             02 01

20170517 082658.185   CONNECT           <---                                      04 00 03 0E 10 63 6C 69 65 6E 74 30 32
Segmentation fault

But when I use the Client version from this "https://github.com/ty4tw/AsyncMQTT-SN" there is no problem and the log like this

***************************************************************************
 * MQTT-SN Transparent Gateway
 * Part of Project Paho in Eclipse
 * (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/)
 *
 * Author : Tomoaki YAMAGUCHI
 * Version: 1.1.0
 ***************************************************************************

20170517 082745.773 PahoGateway-01 has been started.

 ConfigFile: ./gateway.conf
 SensorN/W:  API mode 2, Baudrate 9600, SerialDevice /dev/ttyUSB1
 Broker:     localhost : 1883, 8883
 RootCApath: (null)
 RootCAfile: (null)
 CertKey:    (null)
 PrivateKey: (null)


20170517 082751.038   SEARCHGW          <---  Client                              01 00
20170517 082751.038   GWINFO            --->  Clients                             02 01

20170517 082751.170   CONNECT           <---  client01                            04 0C 01 01 2C 63 6C 69 65 6E 74 30 31
20170517 082752.011   WILLTOPICREQ      --->  client01                            06
20170517 082752.164   WILLTOPIC         <---  client01                            07 00 74 79 34 74 77 40 67 69 74 68 75 62 2F 77 69 6C 6C 54 6F 70 69 63
20170517 082752.164   WILLMSGREQ        --->  client01                            08
20170517 082752.289   WILLMSG           <---  client01                            09 77 69 6C 6C 4D 65 73 73 61 67 65
20170517 082752.292   CONNECT           --->  client01                            10 39 00 04 4D 51 54 54 04 06 01 2C 00 08 63 6C 69 65 6E 74 30 31 00 16 74 79 34 74 77 40 67 69 74 68 75 62 2F 77 69 6C 6C 54 6F 70 69 63 00 0B 77 69 6C 6C 4D 65 73 73 61 67 65
20170517 082752.781   CONNACK           <---  client01                            20 02 00 00
20170517 082752.781   CONNACK           --->  client01                            05 00

20170517 082752.944   SUBSCRIBE   0003  <---  client01                            12 20 00 03 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78
20170517 082752.944   SUBSCRIBE   0003  --->  client01                            82 1D 00 03 00 18 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78 01
20170517 082752.945   SUBACK      0003  <---  client01                            90 03 00 03 01
20170517 082752.945   SUBACK      0003  --->  client01                            13 20 00 01 00 03 00

20170517 082753.030   REGISTER    0002  <---  client01                            0A 00 00 00 02 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78
20170517 082753.041   REGACK      0002  --->  client01                            0B 00 01 00 02 00

20170517 082753.168   PUBLISH     0001  <---  client01                            0C 20 00 01 00 01 C2
20170517 082753.169   PUBLISH     0001  --->  client01                            32 1D 00 18 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78 00 01 C2
20170517 082753.169   PUBACK      0001  <---  client01                            40 02 00 01

20170517 082753.169   PUBLISH     000D  <---  client01                            32 1D 00 18 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78 00 0D C2
20170517 082753.169   PUBACK      0001  --->  client01                            0D 00 01 00 01 00
20170517 082753.227   PUBLISH     000D  --->  client01                            0C 20 00 01 00 0D C2
20170517 082753.356   PUBACK      000D  <---  client01                            0D 00 01 00 0D 00
20170517 082753.356   PUBACK      000D  --->  client01                            40 02 00 0D

20170517 082803.109   SUBSCRIBE   0003  <---  client01                            12 A0 00 03 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78
20170517 082803.109   SUBSCRIBE   0003  --->  client01                            82 1D 00 03 00 18 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78 01
20170517 082803.109   SUBACK      0003  <---  client01                            90 03 00 03 01
20170517 082803.110   SUBACK      0003  --->  client01                            13 20 00 01 00 03 00

20170517 082803.240   PUBLISH     0004  <---  client01                            0C 20 00 01 00 04 C3
20170517 082803.241   PUBACK      0004  <---  client01                            40 02 00 04
20170517 082803.242   PUBLISH     0004  --->  client01                            32 1D 00 18 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78 00 04 C3

20170517 082803.242   PUBLISH     000E  <---  client01                            32 1D 00 18 74 79 34 74 77 40 67 69 74 68 75 62 2F 6F 6E 6F 66 66 2F 6C 69 6E 75 78 00 0E C3
20170517 082803.242   PUBACK      0004  --->  client01                            0D 00 01 00 04 00
20170517 082803.299   PUBLISH     000E  --->  client01                            0C 20 00 01 00 0E C3
20170517 082803.427   PUBACK      000E  <---  client01                            0D 00 01 00 0E 00
20170517 082803.428   PUBACK      000E  --->  client01                            40 02 00 0E

After observing these two log, I think that because the spec of CONNECT changed from 04 0C 01 01 2C to 04 00 03 0E 10 would cause a segfault.

Awaited REGACKs are stored but never evaluated

paho.mqtt-sn.embedded-c/MQTTSNGateway/src/MQTTGWPublishHandler.cpp

Line 145 in bb1af22

client->getWaitREGACKPacketList()->setPacket(snPacket, regackMsgId);

Or am I missing something?

Furthermore the WaitREGACKPacketList causes double-frees in its destructor when SIGINT is raised. I haven't traced down yet, where the other free (or delete) is called.

MQTT-SN Gateway does not support QoS -1.

If you send a message with QoS -1, the gateway treats you like a bad client:

20161012 040143.368   PUBLISH     0000  <---  Non Active Client !                 0C 62 58 31 00 00 41

===> Send:     7e 00 10 10 01 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  02 18   checksum   00
 7e
===> Recv:     00 07 8b 01 4a 81 24 00 00 84    checksum ok
20161012 040143.455   DISCONNECT        --->  Non Active Client !                 18

Note here i have used a short topic; the packet library also seems to support some non-standard (1.2 standard..) inline topic name using a "normal" topic, while the 1.2 standard says only short and pre-defined topics are support. It would be nice to support the library normal topic method as well to allow longer topics in QoS -1

Allow Gateway to run on MacOS

This would be really useful!

Gateway Tester - SLEEP MODE

Hi,
I'm currently testing MQTTSNGateway on Raspberry Pi 3 and running Gateway Tester on my pc. I found out that keep-alive must be shorter than sleep duration. If it’s the other way around, it takes into account for sleep duration the value of keep-alive.
Current configuration:

/*------------------------------------------------------
 *    Client Configuration  (theMqcon)
 *------------------------------------------------------*/
MQTTSNCONF = {
	60,            //KeepAlive [seconds]
	true,          //Clean session
	120,           //Sleep duration [seconds]
	"",            //WillTopic
	"",            //WillMessage
    0,             //WillQos
    false          //WillRetain
};

If I want that client sleeps for 120 sec, client will send PINGREQ every 60 sec (keep-alive value), wouldn't it be correct if client sends just one PINGREQ at the end of sleep duration?

gateway with xbee sensornet type killed by ctrl+c but not exit and still hang there

I want compile a gateway work in xbee network , but when i press ctrl+c , the gateway exited but can not exit to linux console ,only hang there
when i press ctrl + z it stopped on background

Pre-defined TopicID

Pre-definedID is not supported.

Feature: MQTT-SN C++ embedded client

migrated from Bugzilla #444080
status RESOLVED severity enhancement in component MQTT-SN Embedded C/C++ for ---
Reported in version v0.5 on platform PC
Assigned to: Ian Craggs

On 2014-09-15 06:36:01 -0400, Ian Craggs wrote:

An MQTT-SN embedded C++ client, in a similar style of API as the MQTT embedded C++ client. Particularly suitable for use in environments such as mbed and Arduino.

On 2015-02-26 19:08:38 -0500, Ian Craggs wrote:

As I have a talk about MQTT-SN coming up at EclipseCon, I wanted to make some further progress on embedded MQTT-SN APIs for Paho, so that's what I've been doing this week.

I've just published the first pass MQTTSNClient C++ API on mbed (http://developer.mbed.org/users/icraggs/), along with a sample program that uses it over UDP (I will be dragging this code back into Paho soon). I tested it with RSMB. My next plan is a gateway to MQTT using the same base code, as well as trying other software that I know exists (such as https://github.com/ty4tw/MQTT-SN).

On 2015-04-13 06:10:02 -0400, Ian Craggs wrote:

The code is now in the Paho repository. http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/

Packet logging functions need buffer length checks

MQTTGWPacket::print() and MQTTSNPacket::print() do not validate the length of the output buffer. As a result, incoming payload data (e.g a broker's PUBLISH message to a subscribed client) that exceeds 478 characters will cause an out-of-bounds buffer write - with obvious consequences.

One way to defend (for both classes) would be to add a buffer limit parameter (size_t logspace) and use it like this

::print(char* pbuf, const size_t logspace)
{
  for (int i = 0; i < len; i++)
  {
    if (*pptr < (ptr+logspace-4))
    {
      sprintf(*pptr, " %02X", packetData[i]);
      *pptr += 3;
    }
  }

All callers of this member function need to be updated with the extra parameter (usually sizeof(pbuf) ) which means a total of about 20 edits across client and broker send/receive modules.

MQTTSN-Gateway: When using more then one xbee, segfaults.

Have two xbee clients doing periodic publishes, so when the gateway comes up, they will both reconnect. This always causes a seg fault.

 ***************************************************************************
 * MQTT-SN Transparent Gateway
 * Part of Project Paho in Eclipse
 * (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/)
 *
 * Author : Tomoaki YAMAGUCHI
 * Version: 0.9.0
 ***************************************************************************

20161012 203808.829 PahoGateway-01 has been started.

 ConfigFile:  ./gateway.conf
 SensorN/W:   API mode 1, Baudrate 9600, SerialDevice /dev/ttyUSB1
 Broker:      localhost : 1883, 8883
 RootCApath:  (null)
 RootCAfile:  (null)
 ClientCerts: (null)
 00 59 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7e
===> Recv:     00 0f 90 00 13 a2 00 40 a6 92 b1 8b 00 01 03 09 30 c9    checksum ok
20161012 203809.097   WILLMSG           <---  Non Active Client !                 09 30

===> Send:     7e 00 10 10 01 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  02 18   checksum   6b
 7e
===> Recv:     00 07 8b 01 8b 00 00 00 00 e8    checksum ok
20161012 203809.152   DISCONNECT        --->  Non Active Client !                 18
 7e
===> Recv:     00 1e 90 00 13 a2 00 40 a6 92 b1 8b 00 01 12 04 0c 01 00 3c 53 6f 6d 65 43 6c 69 65 6e 74 49 44 26    checksum ok

20161012 203809.235   CONNECT           <---  SomeClientID                        04 0C 01 00 3C 53 6F 6D 65 43 6C 69 65 6E 74 49 44
     PacketHandleTask gets CONNECT      from the client.

===> Send:     7e 00 10 10 02 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  02 06   checksum   7c
 7e
===> Recv:     00 07 8b 02 8b 00 00 00 00 e7    checksum ok
20161012 203809.290   WILLTOPICREQ      --->  SomeClientID                        06
 7e
===> Recv:     00 20 90 00 13 a2 00 40 a6 92 b1 8b 00 01 14 07 10 6d 71 74 74 73 6e 74 65 73 74 2f 73 74 61 74 75 73 a0    checksum ok
20161012 203809.376   WILLTOPIC         <---  SomeClientID                        07 10 6D 71 74 74 73 6E 74 65 73 74 2F 73 74 61 74 75 73
     PacketHandleTask gets WILLTOPIC      from the client.

===> Send:     7e 00 10 10 03 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  02 08   checksum   79
 7e
===> Recv:     00 07 8b 03 8b 00 00 00 00 e6    checksum ok
20161012 203809.433   WILLMSGREQ        --->  SomeClientID                        08
 7e
===> Recv:     00 0f 90 00 13 a2 00 40 a6 92 b1 8b 00 01 03 09 30 c9    checksum ok
20161012 203809.489   WILLMSG           <---  SomeClientID                        09 30
     PacketHandleTask gets WILLMSG      from the client.
20161012 203809.512   CONNECT           --->  SomeClientID                        10 2E 00 04 4D 51 54 54 04 26 00 3C 00 0C 53 6F 6D 65 43 6C 69 65 6E 74 49 44 00 11 6D 71 74 74 73 6E 74 65 73 74 2F 73 74 61 74 75 73 00 01 30
20161012 203809.517   CONNACK           <---  SomeClientID                        20 02 00 00
     PacketHandleTask gets CONNACK      from the broker.

===> Send:     7e 00 11 10 04 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  03 05 00   checksum   7a
 7e
===> Recv:     00 07 8b 04 8b 00 00 00 00 e5    checksum ok
20161012 203809.576   CONNACK           --->  SomeClientID                        05 00
 7e
===> Recv:     00 23 90 00 13 a2 00 40 a6 92 b1 8b 00 01 17 0a 00 00 00 52 6d 71 74 74 73 6e 74 65 73 74 2f 73 74 61 74 75 73 58    checksum ok

20161012 203809.672   REGISTER    0052  <---  SomeClientID                        0A 00 00 00 52 6D 71 74 74 73 6E 74 65 73 74 2F 73 74 61 74 75 73
     PacketHandleTask gets REGISTER  0052 from the client.

===> Send:     7e 00 15 10 05 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  07 0b 00 01 00 52 00   checksum   1c
 7e
===> Recv:     00 07 8b 05 8b 00 00 00 00 e4    checksum ok
20161012 203809.732   REGACK      0052  --->  SomeClientID                        0B 00 01 00 52 00
 7e
===> Recv:     00 24 90 00 13 a2 00 40 a6 92 b1 8b 00 01 18 0a 00 00 00 53 6d 71 74 74 73 6e 74 65 73 74 2f 43 6f 75 6e 74 65 72 1a    checksum ok

20161012 203809.846   REGISTER    0053  <---  SomeClientID                        0A 00 00 00 53 6D 71 74 74 73 6E 74 65 73 74 2F 43 6F 75 6E 74 65 72
     PacketHandleTask gets REGISTER  0053 from the client.

===> Send:     7e 00 15 10 06 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  07 0b 00 02 00 53 00   checksum   19
 7e
===> Recv:     00 07 8b 06 8b 00 00 00 00 e3    checksum ok
20161012 203809.906   REGACK      0053  --->  SomeClientID                        0B 00 02 00 53 00
 7e
===> Recv:     00 22 90 00 13 a2 00 40 a6 92 b1 8b 00 01 16 12 00 00 54 6d 71 74 74 73 6e 74 65 73 74 2f 70 69 6e 2f 31 32 1a    checksum ok

20161012 203810.012   SUBSCRIBE   0054  <---  SomeClientID                        12 00 00 54 6D 71 74 74 73 6E 74 65 73 74 2F 70 69 6E 2F 31 32
     PacketHandleTask gets SUBSCRIBE  0054 from the client.
20161012 203810.016   SUBSCRIBE   0054  --->  SomeClientID                        82 16 00 54 00 11 6D 71 74 74 73 6E 74 65 73 74 2F 70 69 6E 2F 31 32 00
20161012 203810.019   SUBACK      0054  <---  SomeClientID                        90 03 00 54 00
     PacketHandleTask gets SUBACK  0054 from the broker.

===> Send:     7e 00 16 10 07 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  08 13 00 00 03 00 54 00   checksum   0d
 7e
===> Recv:     00 07 8b 07 8b 00 00 00 00 e2    checksum ok
20161012 203810.082   SUBACK      0054  --->  SomeClientID                        13 00 00 03 00 54 00
 7e
===> Recv:     00 22 90 00 13 a2 00 40 a6 92 b1 8b 00 01 16 12 00 00 55 6d 71 74 74 73 6e 74 65 73 74 2f 70 69 6e 2f 31 33 18    checksum ok

20161012 203810.184   SUBSCRIBE   0055  <---  SomeClientID                        12 00 00 55 6D 71 74 74 73 6E 74 65 73 74 2F 70 69 6E 2F 31 33
     PacketHandleTask gets SUBSCRIBE  0055 from the client.
20161012 203810.188   SUBSCRIBE   0055  --->  SomeClientID                        82 16 00 55 00 11 6D 71 74 74 73 6E 74 65 73 74 2F 70 69 6E 2F 31 33 00
20161012 203810.190   SUBACK      0055  <---  SomeClientID                        90 03 00 55 00
     PacketHandleTask gets SUBACK  0055 from the broker.

===> Send:     7e 00 16 10 08 00 13 a2 00 40 a6 92 b1 8b 00 00 00
     Payload:  08 13 00 00 04 00 55 00   checksum   0a
 7e
===> Recv:     00 07 8b 08 8b 00 00 00 00 e1    checksum ok
20161012 203810.252   SUBACK      0055  --->  SomeClientID                        13 00 00 04 00 55 00
 7e
===> Recv:     00 15 90 00 13 a2 00 40 a6 92 b1 8b 00 01 09 0c 10 00 01 00 00 31 00 ae    checksum ok

20161012 203810.330   PUBLISH     0000  <---  SomeClientID                        0C 10 00 01 00 00 31 00
     PacketHandleTask gets PUBLISH  0000 from the client.
20161012 203810.334   PUBLISH     0000  --->  SomeClientID                        31 15 00 11 6D 71 74 74 73 6E 74 65 73 74 2F 73 74 61 74 75 73 31 00
 7e
===> Recv:     00 14 90 00 13 a2 00 40 a6 92 b1 8b 00 01 08 0c 00 00 02 00 00 33 bc    checksum ok

20161012 203810.355   PUBLISH     0000  <---  SomeClientID                        0C 00 00 02 00 00 33
     PacketHandleTask gets PUBLISH  0000 from the client.
20161012 203810.357   PUBLISH     0000  --->  SomeClientID                        30 15 00 12 6D 71 74 74 73 6E 74 65 73 74 2F 43 6F 75 6E 74 65 72 33
 7e
===> Recv:     00 14 90 00 13 a2 00 40 f1 6e b5 4a 81 01 08 0c 62 58 31 00 00 43 58    checksum ok

20161012 203810.988   PUBLISH     0000  <---  Non Active Client !                 0C 62 58 31 00 00 43

===> Send:     7e 00 10 10 09 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  02 18   checksum   f8
 7e
===> Recv:     00 07 8b 09 4a 81 00 00 00 a0    checksum ok
20161012 203811.071   DISCONNECT        --->  SomeClientID                        18
 7e
===> Recv:     00 21 90 00 13 a2 00 40 f1 6e b5 4a 81 01 15 04 0c 01 00 3c 41 6e 6f 74 68 65 72 43 6c 69 65 6e 74 49 44 7b    checksum ok

20161012 203811.197   CONNECT           <---  AnotherClientID                     04 0C 01 00 3C 41 6E 6F 74 68 65 72 43 6C 69 65 6E 74 49 44
     PacketHandleTask gets CONNECT      from the client.

===> Send:     7e 00 10 10 0a 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  02 06   checksum   09
 7e
===> Recv:     00 07 8b 0a 4a 81 00 00 00 9f    checksum ok
20161012 203811.322   WILLTOPICREQ      --->  AnotherClientID                     06
 7e
===> Recv:     00 1b 90 00 13 a2 00 40 f1 6e b5 4a 81 01 0f 07 10 74 65 73 74 32 2f 73 74 61 74 75 73 af    checksum ok
20161012 203811.403   WILLTOPIC         <---  AnotherClientID                     07 10 74 65 73 74 32 2F 73 74 61 74 75 73
     PacketHandleTask gets WILLTOPIC      from the client.

===> Send:     7e 00 10 10 0b 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  02 08   checksum   06
 7e
===> Recv:     00 07 8b 0b 4a 81 00 00 00 9e    checksum ok
20161012 203811.488   WILLMSGREQ        --->  AnotherClientID                     08
 7e
===> Recv:     00 0f 90 00 13 a2 00 40 f1 6e b5 4a 81 01 03 09 30 5e    checksum ok
20161012 203811.535   WILLMSG           <---  AnotherClientID                     09 30
     PacketHandleTask gets WILLMSG      from the client.
20161012 203811.545   CONNECT           --->  AnotherClientID                     10 2C 00 04 4D 51 54 54 04 26 00 3C 00 0F 41 6E 6F 74 68 65 72 43 6C 69 65 6E 74 49 44 00 0C 74 65 73 74 32 2F 73 74 61 74 75 73 00 01 30
20161012 203811.694   CONNACK           <---  AnotherClientID                     20 02 00 00
     PacketHandleTask gets CONNACK      from the broker.

===> Send:     7e 00 11 10 0c 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  03 05 00   checksum   07
 7e
===> Recv:     00 07 8b 0c 4a 81 00 00 00 9d    checksum ok
20161012 203811.774   CONNACK           --->  AnotherClientID                     05 00
 7e
===> Recv:     00 1e 90 00 13 a2 00 40 f1 6e b5 4a 81 01 12 0a 00 00 00 15 74 65 73 74 32 2f 73 74 61 74 75 73 a4    checksum ok

20161012 203811.913   REGISTER    0015  <---  AnotherClientID                     0A 00 00 00 15 74 65 73 74 32 2F 73 74 61 74 75 73
     PacketHandleTask gets REGISTER  0015 from the client.

===> Send:     7e 00 15 10 0d 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  07 0b 00 01 00 15 00   checksum   e6
 7e
===> Recv:     00 07 8b 0d 4a 81 00 00 00 9c    checksum ok
20161012 203811.991   REGACK      0015  --->  AnotherClientID                     0B 00 01 00 15 00
 7e
===> Recv:     00 1b 90 00 13 a2 00 40 f1 6e b5 4a 81 01 0f 0a 00 00 00 16 74 65 73 74 32 2f 73 77 30 30    checksum ok

20161012 203812.087   REGISTER    0016  <---  AnotherClientID                     0A 00 00 00 16 74 65 73 74 32 2F 73 77 30
     PacketHandleTask gets REGISTER  0016 from the client.

===> Send:     7e 00 15 10 0e 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  07 0b 00 02 00 16 00   checksum   e3
 7e
===> Recv:     00 07 8b 0e 4a 81 00 00 00 9b    checksum ok
20161012 203812.217   REGACK      0016  --->  AnotherClientID                     0B 00 02 00 16 00
 7e
===> Recv:     00 1d 90 00 13 a2 00 40 f1 6e b5 4a 81 01 11 12 00 00 17 74 65 73 74 32 2f 70 69 6e 2f 31 32 66    checksum ok

20161012 203812.278   SUBSCRIBE   0017  <---  AnotherClientID                     12 00 00 17 74 65 73 74 32 2F 70 69 6E 2F 31 32
     PacketHandleTask gets SUBSCRIBE  0017 from the client.
20161012 203812.282   SUBSCRIBE   0017  --->  AnotherClientID                     82 11 00 17 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 32 00
20161012 203812.284   SUBACK      0017  <---  AnotherClientID                     90 03 00 17 00

20161012 203812.285   PUBLISH     0000  <---  AnotherClientID                     31 0F 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 32 30
     PacketHandleTask gets SUBACK  0017 from the broker.
     PacketHandleTask gets PUBLISH  0000 from the broker.

===> Send:     7e 00 16 10 0f 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  08 13 00 00 03 00 17 00   checksum   d7
 7e
===> Recv:     00 07 8b 0f 4a 81 00 00 00 9a    checksum ok
20161012 203812.364   SUBACK      0017  --->  AnotherClientID                     13 00 00 03 00 17 00
 7e
===> Recv:     00 1d 90 00 13 a2 00 40 f1 6e b5 4a 81 01 11 12 00 00 18 74 65 73 74 32 2f 70 69 6e 2f 31 33 64    checksum ok

20161012 203812.494   SUBSCRIBE   0018  <---  AnotherClientID                     12 00 00 18 74 65 73 74 32 2F 70 69 6E 2F 31 33
     PacketHandleTask gets SUBSCRIBE  0018 from the client.
20161012 203812.498   SUBSCRIBE   0018  --->  AnotherClientID                     82 11 00 18 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 33 00
20161012 203812.500   SUBACK      0018  <---  AnotherClientID                     90 03 00 18 00

20161012 203812.501   PUBLISH     0000  <---  AnotherClientID                     31 0F 00 0C 74 65 73 74 32 2F 70 69 6E 2F 31 33 31
     PacketHandleTask gets SUBACK  0018 from the broker.
     PacketHandleTask gets PUBLISH  0000 from the broker.

===> Send:     7e 00 16 10 10 00 13 a2 00 40 f1 6e b5 4a 81 00 00
     Payload:  08 0c 10 00 03 00 00 30   checksum   b4
 7e
===> Recv:     00 07 8b 10 4a 81 00 00 00 99    checksum ok
20161012 203812.591   PUBLISH     0000  --->  AnotherClientID                     0C 10 00 03 00 00 30
 7e
===> Recv:     00 14 90 00 13 a2 00 40 f1 6e b5 4a 81 01 08 0c 62 58 31 00 00 41 5a    checksum ok

20161012 203815.969   PUBLISH     0000  <---  AnotherClientID                     0C 62 58 31 00 00 41
     PacketHandleTask gets PUBLISH  0000 from the client.
20161012 203815.977   PUBLISH     0000  --->  AnotherClientID                     36 07 00 02 58 31 00 00 41
 7e
===> Recv:     00 14 90 00 13 a2 00 40 f1 6e b5 4a 81 01 08 0c 62 58 31 00 00 42 59    checksum ok

20161012 203820.966   PUBLISH     0000  <---  AnotherClientID                     0C 62 58 31 00 00 42
     PacketHandleTask gets PUBLISH  0000 from the client.
20161012 203820.969   PUBLISH     0000  --->  AnotherClientID                     36 07 00 02 58 31 00 00 42
 7e
===> Recv:     00 1d 90 00 13 a2 00 40 f1 6e b5 4a 81 01 11 12 80 00 18 74 65 73 74 32 2f 70 69 6e 2f 31 33 e4    checksum ok

20161012 203822.390   SUBSCRIBE   0018  <---  AnotherClientID                     12 80 00 18 74 65 73 74 32 2F 70 69 6E 2F 31 33
     PacketHandleTask gets SUBSCRIBE  0018 from the client.
Error: BrokerSendTask can't send a packet to the broker errno=32 AnotherClientID
*** Error in `Build/MQTT-SNGateway': double free or corruption (fasttop): 0xb3f00650 ***
./run_gateway: line 1: 16611 Aborted                 Build/MQTT-SNGateway -f gateway.conf

Use secure connection to the broker by default?

Hi!

As far as I understand the code, MQTTSNGateway uses only secure connections if every possible client ID is listed in the ClientsList and the keyword secureConnection is attached to the client. What do you think of using secure connection by default if BrokerSecurePortNo, RootCAfile (or RootCApath), CertKey and PrivateKey is given?

Or do you have any concerns?

Thank you!

Gateway not forwarding SUBACK to sensor net

Once connected, my module tries to subscribe to a topic.
The SUBSCRIBE message is sent to the GW, forwarded to the broker and acknowledged by a SUBACK.

BUT: This SUBACK message is not forwarded to my sensor node:

20170613 114649.490   CONNECT           <---  ToRaDes_123                         04 00 01 00 00 54 6F 52 61 44 65 73 5F 31 32 33 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 B4 E2 FC 3F D0
20170613 114649.491   CONNECT           --->  ToRaDes_123                         10 17 00 04 4D 51 54 54 04 00 00 00 00 0B 54 6F 52 61 44 65 73 5F 31 32 33
20170613 114649.842   CONNACK           <---  ToRaDes_123                         20 02 01 00
20170613 114649.842   CONNACK           --->  ToRaDes_123                         05 00
unicast sendto fe80::240a:c4ff:fe04:b132%bt0, port: 448 length = 3

20170613 114649.980   SUBSCRIBE   0000  <---  ToRaDes_123                         12 00 00 00 2F 6C 69 67 68 74 2F 62 72 69 67 68 74 6E 65 73 73 00 00 7F 11 24 0A C4 FF FE 04 B1 32 02 1A 7D FF
20170613 114649.981   SUBSCRIBE   0000  --->  ToRaDes_123                         82 16 00 00 00 11 2F 6C 69 67 68 74 2F 62 72 69 67 68 74 6E 65 73 73 00
20170613 114649.982   SUBACK      0000  <---  ToRaDes_123                         90 03 00 00 00

Is it possible that I made an error regarding the sequence or is this related to the GW?

BTW: "unicast sento..." is a message from the UDP6 sensor net, just for debugging here. So nothing is sent to the output interface.

MQTT-SN Forwarder

Has anyone considered implementing a MQTT-SN Forwarder?

I have a desire to be able to implement the following:

MQTT-SN Client <--2.4GHz packet radio transport--> MQTT-SN Forwarder <--serial transport--> MQTT-SN Gateway <--IP transport--> MQTT Broker

So I'm looking for a forwarder with plugable transport on each side. I'm open to pointer elsewhere, or, if welcome here, I might start looking at creating one based on the existing code here for contribution back?

Rob.

Bluetooth LE support for the Gateway

To allow this scenario https://blog.benjamin-cabe.com/2017/01/16/using-mqtt-sn-over-ble-with-the-bbc-microbit to work better.

Gateway: some warnings on build on Ubuntu

MQTTSNGateway/src/linux/Timer.cpp: In member function ‘void MQTTSNGW::LightIndicator::lit(int, const char_)’:
MQTTSNGateway/src/linux/Timer.cpp:187:33: warning: ignoring return value of ‘ssize_t write(int, const void_, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
write(gpio[gpioNo], onoff, 1);
^
MQTTSNGateway/src/linux/Timer.cpp: In member function ‘void MQTTSNGW::LightIndicator::pinMode(int)’:
MQTTSNGateway/src/linux/Timer.cpp:200:27: warning: ignoring return value of ‘ssize_t write(int, const void, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
write(fd, no, strlen(no));
^
MQTTSNGateway/src/linux/Timer.cpp:211:20: warning: ignoring return value of ‘ssize_t write(int, const void_, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
write(fd,"out", 3);

CONTRIBUTING.md out of date

In particular bug reporting still points to eclipse bugzilla.

Persistent client subscription

I´m trying to make persistent subscribtions on MQTT-SN Gateway. For getting that I'm using a command line MQTT-SN client executing:

./mqtt-sn-sub -p 5223 -t "test" -c -q 1 -i "receiver"

From the command line client I make a publication using
./mqtt-sn-pub -p 5223 -t "test" -m "hello" -q 1 -i "publisher"

If the receiver is connected when I launch the publication, the message arrives as expected.

But if I execute the following steps:

1. Create a subscription to topic 'test' with clean session to false:
   ./mqtt-sn-sub -p 5223 -t "test" -c -q 1 -i "receiver"

2. Disconnect the receiver form the GW

3. Publish on 'test' topic
   ./mqtt-sn-pub -p 5223 -t "test" -m "hello" -q 1 -i "publisher"

4. Connect to GW with "receiver" Id

No Messages arrives to the receiver and the GW logs show "Invalid Topic. PUBLISH message is canceled.". The complete logs shows:

20180615 122837.132   CONNECT           <---  receiver                            04 00 01 00 0A 72 65 63 65 69 76 65 72
20180615 122837.133   CONNECT           ===>  receiver                            10 14 00 04 4D 51 54 54 04 00 00 0A 00 08 72 65 63 65 69 76 65 72
20180615 122837.173   CONNACK           <===  receiver                            20 02 01 00
20180615 122837.173   CONNACK           --->  receiver                            05 00

20180615 122837.173   SUBSCRIBE   0001  <---  receiver                            12 20 00 01 74 65 73 74
20180615 122837.174   SUBSCRIBE   0001  ===>  receiver                            82 09 00 01 00 04 74 65 73 74 01
20180615 122837.174   SUBACK      0001  <===  receiver                            90 03 00 01 01
20180615 122837.174   SUBACK      0001  --->  receiver                            13 20 00 01 00 01 00
20180615 122840.567   DISCONNECT        <---  receiver                            18
20180615 122840.567   DISCONNECT        --->  receiver                            18
20180615 122840.567   DISCONNECT        ===>  receiver                            E0 00
20180615 122842.000   ADVERTISE         --->  Clients                             00 02 03 84

20180615 122847.084   CONNECT           <---  publisher                           04 04 01 00 0A 70 75 62 6C 69 73 68 65 72
20180615 122847.085   CONNECT           ===>  publisher                           10 15 00 04 4D 51 54 54 04 02 00 0A 00 09 70 75 62 6C 69 73 68 65 72
20180615 122847.104   CONNACK           <===  publisher                           20 02 00 00
20180615 122847.104   CONNACK           --->  publisher                           05 00

20180615 122847.104   REGISTER    0001  <---  publisher                           0A 00 00 00 01 74 65 73 74
20180615 122847.104   REGACK      0001  --->  publisher                           0B 00 01 00 01 00

20180615 122847.105   PUBLISH     0002  <---  publisher                           0C 20 00 01 00 02 68 65 6C 6C 6F
20180615 122847.105   PUBLISH     0002  ===>  publisher                           32 0D 00 04 74 65 73 74 00 02 68 65 6C 6C 6F
20180615 122847.105   PUBACK      0002  <===  publisher                           40 02 00 02
20180615 122847.105   PUBACK      0002  --->  publisher                           0D 00 01 00 02 00
20180615 122847.106   DISCONNECT        <---  publisher                           18
20180615 122847.106   DISCONNECT        --->  publisher                           18
20180615 122847.106   DISCONNECT        ===> !                                  E0 00

20180615 122851.724   CONNECT           <---  receiver                            04 00 01 00 0A 72 65 63 65 69 76 65 72
20180615 122851.724   CONNECT           ===>  receiver                            10 14 00 04 4D 51 54 54 04 00 00 0A 00 08 72 65 63 65 69 76 65 72
20180615 122852.108   CONNACK           <===  receiver                            20 02 01 00
20180615 122852.108   CONNACK           --->  receiver                            05 00

20180615 122852.108   PUBLISH     0007  <===  receiver                            32 0D 00 04 74 65 73 74 00 07 68 65 6C 6C 6F
 Invalid Topic. PUBLISH message is canceled.
20180615 122852.108   PUBACK      0007  ===>  receiver                            40 02 00 07

20180615 122852.108   SUBSCRIBE   0001  <---  receiver                            12 20 00 01 74 65 73 74
20180615 122852.109   SUBSCRIBE   0001  ===>  receiver                            82 09 00 01 00 04 74 65 73 74 01
20180615 122852.154   SUBACK      0001  <===  receiver                            90 03 00 01 01
20180615 122852.154   SUBACK      0001  --->  receiver                            13 20 00 01 00 01 00

Are presistent subscriptions availables with the current GW implementation?

Maybe I´m doing something wrong or missing something. Any help is wellcome.

Thanks in advance

Add Travis-CI automated build and test

Hi Tomoaki.

It would be very good if you could add Travis build and tests to this repository, like I have for the C client repo. This will also allow you run Mac build and tests, if you wish. The Travis configuration in the C client repository should help you.

MQTT-SN Gateway - sleepy node problem

Hi,

I am using the MQTT-SN Gateway with two client nodes: first one subscribes to a topic and goes to asleep state, second one publishes data on that topic. It should result in the subscriber node getting the data in between PINGREQ and PINGRESP messages, but it happens only once. After the first keep-alive procedure done by the subscriber in asleep state, the node is kept in an undefined state. The gateway pushes PUBLISH messages outside of the PINGREQ - PINGRESP period, but does not receive PUBACK response. I have attached a log from the gateway to clarify. As you can see in the log, first PUBLISH to the sleeping client is saved and forwarded to the node between PINGREQ and PINGRESP. After the PINGRESP, the publisher node sends PUBLISH message again, but this time it is forwarded immediately, but PUBACK is not received, so the PUBLISH is retransmitted. No more PUBLISH messages are sent later from the publisher node, all the PUBLISH messages are retransmissions and not received PUBACKs.

In this log, the client is asleep only on the MQTT-SN layer so that not receiving PUBACKs is visible.
mqttsn_gateway_log.txt

topic name has 2 chars segment fault

when client subscribe with 2 chars topic name, ex. "aa" or "tt", the daemon MQTTGATEWAY exception with segment fault

subscribe example:
mqtt-sn-sub -h mqtt_server -p port -t 'aa'
when subscribed, the MQTTSNGATEWAY will exited with segmentation fault!

Using the Gateway

Tomoaki,

I've just been trying out the gateway. Started up first time, which is great :-)

I've been using the client sample programs in MQTTSNPacket/samples

qos0pub_register: the first message gets sent, but then the gateway crashes:

20160809 215541 154 PUBLISH 0000 ---> d:quickstart:udptest:9002f7f1ad23 30 FF 01 00 19 69 6F 74 2D 32 2F 65 76 74 2F 73 74 61 74 75 73 2F 66 6D 74 2F 6A 73 6F 6E 00 00 7B 22 64 22 3A 7B 22 6D 79 4E 61 6D 65 22 3A 22 49 6F 54 20 6D 62 65 64 22 2C 22 61 63 63 65 6C 58 22 3A 31 32 2E 30 30 30 30 2C 22 61 63 63 65 6C 59 22 3A 31 30 2E 30 30 30 30 2C 22 61 63 63 65 6C 5A 22 3A 36 2E 30 30 30 30 2C 22 74 65 6D 70 22 3A 32 33 2E 30 30 30 30 2C 22 6A 6F 79 73 74 69 63
*** stack smashing detected ***: ../Build/MQTT-SNGateway terminated
Aborted (core dumped)

qos0pub and qos01pub don't seem to work quite right - but I haven't figured out exactly what is going on yet. I'll get more information if you don't first!

MQTT-SN to MQTT embedded transparent gateway

migrated from Bugzilla #444079
status NEW severity enhancement in component MQTT-SN Embedded C/C++ for ---
Reported in version unspecified on platform PC
Assigned to: Al Stockdill-Mander

On 2014-09-15 06:32:52 -0400, Ian Craggs wrote:

Now we have an MQTT-SN embedded client, it would be good to have an MQTT-SN to MQTT transparent gateway using the embedded clients. It should allow any MQTT-SN transport to be used - UDP, ZigBee, serial, for instance, and in the same way as the other higher level embedded code:

1. not use any system libraries, unless they are pluggable
2. not use any dynamic memory allocation
3. use C++ at least to start with

Consider adding support for DTLS

Currently, MQTT-SN doesn't provide any security. Till lately it would make perfect sense: TLS doesn't support UDP. But now we have DTLS.

Especially DTLS+PSK could be useful, because it creates much smaller overhead than exchanging certificates and it can be used for authentication.

If you don't want it in upstream, because MQTT-SN with DTLS has not been standardized yet, I'd be extremely grateful even for a simplified implementation example with mbed-tls in wiki.

Reformatting to make more consistent; split exit: and FUNC_EXIT_RC on to separate lines

migrated from Bugzilla #453862
status RESOLVED severity normal in component MQTT-SN Embedded C/C++ for 1.1
Reported in version unspecified on platform All
Assigned to: Ian Craggs

Original attachment names and IDs:

• 453862.diff (ID 249091)

On 2014-12-02 06:43:30 -0500, Nicholas Humfrey wrote:

Hello,

I have made a couple of minor changes to split "exit:" and FUNC_EXIT_RC on to separate lines - this standardises the formatting in codebase.

The reason why I have done this is it makes it easier to strip out the FUNC_ macros from the codebase automatically.

My git commit is here:
https://github.com/njh/org.eclipse.paho.mqtt-sn.embedded-c/commit/SHA: 077d1ad3505a1f697035bda875a631d679821c1d

nick.

This contribution complies with http://www.eclipse.org/legal/CoO.php

On 2014-12-02 06:44:42 -0500, Nicholas Humfrey wrote:

Created attachment 249091
split exit: and FUNC_EXIT_RC on to separate lines

On 2015-02-20 11:24:21 -0500, Ian Craggs wrote:

Hi Nicholas,

to push this to the repository with you as author, you have to register with Gerrit, apparently, as we do use Gerrit. I think this is as simple as logging into https://git.eclipse.org/r/#/.

On 2015-04-09 10:30:18 -0400, Ian Craggs wrote:

Now, done. Thanks Nicholas

CONNECT primitive with empty ClientId

A misbehaving client that sends CONNECT towards the GW with a zero-length ClientId field will crash the gateway.

Function MQTTSNDeserialize_connect() does not validate against the error condition:

(data->clientID.lenstring.data == NULL)

and hence a null string is deferenced later in the receive task (most likely by the logging functions)

Gateway needs documentation

Contributing guideline seems to be outdated

It looks like Eclipse CLA is deprecated.
Should Eclipse Contributor Agreement be use instead?

subscribe to all topics with “#” ，GW return with ‘invalid topic， publish message is canceled’

when I subscribe to all topics with Wildcard ‘#’ , return with success.

But when GW received a message and publish to me , GW will throw a message ‘invalid topic， publish message is canceled’

DISCONNECT handling

Paul Kierstead wrote,
So, I tweaked TLS_client_method to be TLSv1_2_client_method and it compiles fine on the PI (but I presume this limits it to TLS1.2, which is fine by me...) and it #29 is working quite well on the PI. My previous complaints are all nicely addressed :)

Here is one thing that is sort of I think is only hinted at by the standard, which I implemented in previous gateway, but seems "open". Let say I power-cycle/etc the gateway. Now, the client keeps on going ... and sends a publish. The gateway ignores the client: "Not an active client". It would be really useful if the gateway sent back a DISCONNECT so that the client could immediately re-establish the connection. Otherwise, a client sending QoS 0 messages doesn't know it is no longer connected and all the messages go to /dev/null. I think this is an oversight in the standard (or I've missed it.... I might have even known when I implemented a gateway, but that was quite a while ago). Without it, QoS 0 is almost useless.

'START_BYTE' was not declared

While compiling the gateway project using make SENSORNET=xbee, there is an error saying STAR_BYTE is not declared.
Seems it was removed accidentally on "BugFix of Wildcard of Topic Issue #40".

`#define XMIT_STATUS_TIME_OVER 5000

#define START_BYTE 0x7e
#define ESCAPE 0x7d
#define XON 0x11
#define XOFF 0x13`

MQTTSN Gateway -- Sends spurious congestion connack

Tip is "BugFix: Network can not handle EPIPE error."
The log is below. The gateway and my node get stuck in a loop doing this sequence (pretty much exactly this) over and over. Notes:

• The gateway asks for the will topic twice. When we are stuck in this state, it always asks twice. When a connect goes well, it only asks once.
• The gateway first sends an Accepted CONNACK, but then when we attempt to register a topic, it sends a congestion CONNACK.
• Even after telling the node that there is congestion, it still sends a REGACK.
• A very late second will message request appears to happen, but it looks like the logs are out of order (by a lot -- 4 seconds !). Again, this doesn't happen when things are going well.

As a note, in the logs it might be good to more clearly differentiate between end<->Gateway and gateway<->broker other then color, as color doesn't survive cut'n'paste...

If there is any additional logging, etc. you want let me know; this happens often enough that it shouldn't be too hard to reproduce (hopefully)

20161014 024113.345   CONNECT           <---  Client2                             04 0C 01 02 58 43 6C 69 65 6E 74 32
20161014 024113.493   WILLTOPICREQ      --->  Client2                             06
20161014 024113.572   WILLTOPIC         <---  Client2                             07 10 74 65 73 74 32 2F 73 74 61 74 75 73
20161014 024113.662   WILLTOPICREQ      --->  Client2                             06
20161014 024113.740   WILLTOPIC         <---  Client2                             07 10 74 65 73 74 32 2F 73 74 61 74 75 73
20161014 024113.833   WILLMSGREQ        --->  Client2                             08
20161014 024113.886   WILLMSG           <---  Client2                             09 30
20161014 024113.898   CONNECT           --->  Client2                             10 24 00 04 4D 51 54 54 04 26 02 58 00 07 43 6C 69 65 6E 74 32 00 0C 74 65 73 74 32 2F 73 74 61 74 75 73 00 01 30
20161014 024113.903   CONNACK           <---  Client2                             20 02 00 00
20161014 024114.045   WILLMSG           <---  Client2                             09 30
20161014 024118.000   WILLMSGREQ        --->  Client2                             08
20161014 024118.146   CONNACK           --->  Client2                             05 00

20161014 024118.236   REGISTER    0026  <---  Client2                             0A 00 00 00 26 74 65 73 74 32 2F 73 74 61 74 75 73
20161014 024118.376   CONNACK           --->  Client2                             05 01

20161014 024118.406   CONNECT           <---  Client2                             04 0C 01 02 58 43 6C 69 65 6E 74 32
20161014 024118.494   REGACK      0026  --->  Client2                             0B 00 01 00 26 00

Cannot parse DISCONNECT message without duration

The method MQTTSNPacket_read() fails for DISCONNECT messages and returns MQTTSNPACKET_READ_ERROR.

The problem seems to be that the DISCONNECT message is only two bytes long if the optional field "duration" is not set. The library however checks for a minimum message length of 3 (see MQTTSN_MIN_PACKET_LENGTH).

Questions about existing functionality of the MQTT-SN Gateway

So,
it's not a real issue, but I didn't know where to ask my questions.
My goal is to implement a MQTT-SN bridge to a MQTT server.
Is the MQTT-SN Gateway implementation finished?
Because this is what I want to achieve.
Generally, form what I can see, the only working thing is the MQTT-SN Client.
Is there a Server implementation working?
If you can give me pointers what can I use from your existing MQTT and MQTT-SN implementations to build a working MQTT - MQTT-SN Bridge/Gateway.

MQTTSNDeserialize_XXXX() functions don't return error code when error occurs.

Return code rc is over wrote by MQTTSNPacket_decode() function.

curdata += (rc = MQTTSNPacket_decode(curdata, len, &mylen)); /* read length */

should be

curdata +=  MQTTSNPacket_decode(curdata, len, &mylen); /* read length */

MQTT-SN Gateway does not accept client connection

Hi all.

When the number of client connections reaches the upper limit (MAX_CLIENTS), GW will not accept connections from clients.
However, even after the client disconnects and the number of client connections decreases, new client does not connect.
Specifically, GW does not respond to SEARCHGW from client.
Is the number of client connections (_clientCnt) not well managed?

Known Bug of TLS connection which requires a client certificate.

Can not connect to the AWS IoT.

GW does not work when a client subscribes wildcard topic

Hi all.
When a client subscribes wildcard topic (both + and #) and other client publish message of that topic, GW shows CPU Usage 100% and the subscriber doesn't get the publish.
And also, publisher disconnects from GW, reconnect to GW.
However GW doesn't receive CONNECT message.

Please provide example config files for the gateway

PING Between GW <-> SN-Client

Hello all,

Now I'm trying out this gateway and Mr. Tomoaki's ESP8266MQTTSNClient. https://github.com/ty4tw/ESP8266MQTTSNClient

I'm connecting 20 ESP8266Clients and they are gathering temperature, humidity and illuminance per minute.
I hope you inform your testing environment including the test scripts etc.
(Are you testing with MQTTSNPacket?)

In my environment, this GW is working very well!
However, sometimes clients are disconnected from GW due to some of the network trouble(I guess)
and the GW does not seem to recognize its disconnection and keep sending the publishing message.
In such a case, Your proposal, "sending DISCONNECT from GW" sounds good!

I'm thinking to try the procedure in order to improve the transmission rate between SN-Client <-> GW <-> Broker,
the one of the other way is PING between SN-Clinet <-> GW.

Kitagawa@Osaka University

Problem with repeat connects in MQTT Broker

Hi i make a code that works with MQTT, this code send at interval times (15 min) some values to the MQTT broker and they go to sleep. The code works some repetitions but after the MQTT can't connect, if i reset the board the code works again and the problem repeat.

void connect()
{
  char hostname[] = "192.168.104.51";
  int port = 1883;
  int rc = ipstack.connect(hostname, port);
  MQTTPacket_connectData data = MQTTPacket_connectData_initializer;
  data.MQTTVersion = 3;
  data.clientID.cstring = (char*)"probe";
  data.username.cstring = (char*)"probe1";
  data.password.cstring = (char*)"123456";
  rc = client.connect(data);
    rc = client.subscribe(topicSalida, MQTT::QOS0, messageArrived);
  SerialUSB.print("Valor RC: ");  
  SerialUSB.println(rc);
}

void enviarSondas()
{
  MQTT::Message message;

  char buf[200];
  int lenPayload = 0;
  uint8_t *auxPointer = sondasValues();
  int i = 0;  
  for (int i=0; i < 200; i++)
  {
    buf[i] = auxPointer[i];
    //SerialUSB.print(buf[i],HEX);  
    if(buf[i] == '\r')
    {
      lenPayload = i;     
    }
  }
    
  message.qos = MQTT::QOS0;
  message.retained = false;
  message.dup = false;
  message.payload = (void*)buf;
  message.payloadlen = lenPayload;
  int rc = client.publish(topic, message);  
}

void loop() {

  if(conectarPlacaRF() == WL_CONNECTED)
  {
    SerialUSB.println("Placa Wifi Conectada a red");
    if (!client.isConnected())
    {
      SerialUSB.println("Intentando conectar MQTT");      
      connect();
    }
    else
    {         
	  SerialUSB.println("Enviar Sondas");         
	  enviarSondas();            
	  dormir = true;
      
      if (reintentos > 5 || dormir == true)
      {
        SerialUSB.println("Apagar después de enviar");         
        client.disconnect();     
        delay(25);
        WiFi.disconnect(); 
        delay(25);      
        reintentos = 0;
        dormir = false;  
        Serial.flush();
        Serial1.flush();       
        //LowPower.sleep(valorDormir);      
        delay(20000);
      }  
    }  
  }
}

LOG:

Conexión WIFI: 1
Valor RC: 0
Placa Wifi Conectada a red
He llegado
Enviar Sondas
Apagar después de enviar
Conexión WIFI: 1
Valor RC: 0
Placa Wifi Conectada a red
He llegado
Enviar Sondas
Apagar después de enviar
Conexión WIFI: 1
Valor RC: 0
Placa Wifi Conectada a red
He llegado
Enviar Sondas
Apagar después de enviar
Conexión WIFI: 1
Valor RC: 0
Placa Wifi Conectada a red
He llegado
Enviar Sondas
Apagar después de enviar
Conexión WIFI: 1
No socket available
Valor RC: -1
Placa Wifi Conectada a red
Intentando conectar MQTT
No socket available
Valor RC: -1
Conexión WIFI: 1
No socket available
Valor RC: -1

Thanks

How to run MQTTSNClient?

Could you, please, provide a sample with main where we could see how to use MQTTSNClient API?

qos -1 issue

I am using the paho.mqtt-sn.embedded-c and emqtt/emq-sn on Linux platform .
In my test platform,there are two clients.Client A is used to publish message,and Client B is used to subscribe message.
Client A public info:
topic:"hello"
payload:"test"
qos:-1

**I find Client B can not receive any message.**So I trace log :

In client A
Serialize publish message is :10 0C 60 00 05 00 00 68 65 6C 6C 6F 74 65 73 74
10:lenth
0C:PUBLISH FLAG
60: qos is -1
00 05
00 00: packet id
68 65 6C 6C 6F : hello
74 65 73 74 :test

I find the topic length(qos = -1) in MQTTSNSerialize_publish(paho.mqtt-sn.embedded-c/MQTTSNPacket/src/MQTTSNSerializePublish.c) like this:
if (topic.type == MQTTSN_TOPIC_TYPE_NORMAL && qos == 3)
{
/ special arrangement for long topic names in QoS -1 publishes. The length of the topic is in the topicid field /
writeInt(&ptr, topic.data.long_.len); / topic length /
}

From the mqtt-sn spec, there no topic length field.
Could you please tell me why? @icraggs

Message ID is not allowed to be 0

Hi

I discovered, that message with ID 0, are not added to the "TopicIdMap" (in MQTTSNPublishHandler::handlePublish). And it ends up in the following error "PUBACK from the Broker is invalid. PacketID : 0000"

I couldn't find any hint for this specific behavior in the specification, so I assume it's a bug. Is this correct or have I overseen something?

Thanks

Questions on MQTT-SN Gateway

Thanks for the work Tomoaki. I've just been trying out the gateway and I have some questions.

1. Why do we have to create the files rbmutex.key, ringbuffer.key and semaphore.key? Is there a reason why the program can't do this itself?

2. I think the directory in which these files are located should be configurable.

3. You say "This must not be the same machine as the Client." The gateway must not be on the same machine as the client? Why is this the case?

4. Does the example param.conf file need any changes before it will work? I'm getting "can't open the sensor network"

Thanks