eclipse / mosquitto.rsmb

Mosquitto rsmb

RSMB: Really Small Message Broker

The Really Small Message Broker is a server implementation of the MQTT and MQTT-SN protocols. Any client that implements this protocol properly can use this server for sending and receiving messages.

The main reason for using RSMB over the main Mosquitto codebase is that Mosquitto doesn't currently have support for the MQTT-SN protocol.

Project History

After several IBM servers were produced during the 2000s, Really Small Message Broker (RSMB) was released onto IBM alphaWorks in 2008. It's aim was to be a minimalist MQTT server, and according to the usual alphaWorks practices, was closed source and released under an evaluation-only license. During the following two years, it gained a small but enthusiastic following. In 2010, Roger Light learned about MQTT and RSMB from an Andy Stanford-Clark presentation. He created Mosquitto to be an open source alternative to RSMB.

RSMB has had MQTT-SN capabilities added but not released outside of IBM. Now we have the chance to bring Mosquitto and RSMB back together as one Eclipse project, taking advantage of the collaboration of the authors of both previous projects.

You can read more about the background of RSMB on the Eclipse project page for Mosquitto: https://www.eclipse.org/proposals/technology.mosquitto/

Getting started

RSMB has been tested on Linux, Mac OS and Windows.

To compile on Linux and Mac, it should be as simple as:

cd rsmb/src
make

For more detailed information, see the rsmb/doc/gettingstarted.htm document.

Sample Configuration

# Uncomment this to show you packets being sent and received
#trace_output protocol

# Normal MQTT listener
listener 1883 INADDR_ANY
ipv6 true

# MQTT-SN listener
listener 1883 INADDR_ANY mqtts
ipv6 true

For a more complex example, see Ian Craggs' blog post: http://modelbasedtesting.co.uk/?p=44

Links

• Source code repository: https://github.com/eclipse/mosquitto.rsmb
• Find existing bugs or submit a new bug: https://github.com/eclipse/mosquitto.rsmb/issues
• Mailing-list: https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

mosquitto.rsmb's Issues

Broker losses on second SUBSCRIBE

Hello all,

I'd note some strange behavior on my broker after send two SUBSCRIBE messages to the same topic id in sequence. I'm porting a lib. to MQTT-SN and for some reasons I don't acknowledge the first SUBACK message and when I send again to the broker, the broker send me the SUBACK again but when I see the publish messages the topic is something strange....

Must be:

/topic_1 TOPICO 1
/topic_2 TOPICO 2
/topic_3 TOPICO 3
/topic_4 TOPICO 4

What happens:

/topic_1 TOPICO 1
Engine.c TOPICO 2
/topic_3 TOPICO 3
/topic_4 TOPICO 4

Log of the broker

aaaa::c30c:0:0:2:1884 anderson <- MQTT-S SUBSCRIBE msgid: 1 qos: 0 topicIdType 1
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S SUBACK msgid: 1 topicid: 1 returncode: 0 (0)
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S PUBLISH msgid: 0 qos: 0 retained: 1 (0)
FIRST SUBACK LOST BY MY DEVICE:
 aaaa::c30c:0:0:2:1884 anderson <- MQTT-S SUBSCRIBE msgid: 2 qos: 0 topicIdType 1
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S SUBACK msgid: 2 topicid: 2 returncode: 0 (0)
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S PUBLISH msgid: 0 qos: 0 retained: 1 (0)
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S PINGRESP (0)
SECOND SUBACK ACKNOWLEDGE BY MY DEVICE:
 aaaa::c30c:0:0:2:1884 anderson <- MQTT-S SUBSCRIBE msgid: 2 qos: 0 topicIdType 1
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S SUBACK msgid: 2 topicid: 2 returncode: 0 (0)
 aaaa::c30c:0:0:2:1884 anderson <- MQTT-S SUBSCRIBE msgid: 3 qos: 0 topicIdType 1
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S SUBACK msgid: 3 topicid: 3 returncode: 0 (0)
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S PUBLISH msgid: 0 qos: 0 retained: 1 (0)
 aaaa::c30c:0:0:2:1884 anderson <- MQTT-S SUBSCRIBE msgid: 4 qos: 0 topicIdType 1
 aaaa::c30c:0:0:2:1884 anderson -> MQTT-S SUBACK msgid: 4 topicid: 4 returncode: 0 (0)

And in the topic that I send the second SUBSCRIBE the bug happens....

Handling searchGW Messages

migrated from Bugzilla #449044
status ASSIGNED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• gwinfo.patch (ID 248225)

On 2014-10-28 06:32:11 -0400, Mohammad Jamal MohiUddin wrote:

Created attachment 248225
GatewayInfo Patch

There is no implementation for handling of SearchGW Message.Whenever a SearchGW Message is received we have to reply back with a Gateway Info message. The patch provides the following changes....

On 2014-11-11 11:41:46 -0500, Ian Craggs wrote:

Thanks Mohammad. This looks good. As your contribution didn't come in through Gerrit, I have to ask that you confirm that the contribution:

1. Contains No Cryptography
2. Is Developed from Scratch (without incorporating content from elsewhere)
3. Is 100% Project License Code

I know that you have a Eclipse CLA on file :-)

On 2014-11-11 22:47:49 -0500, Mohammad Jamal MohiUddin wrote:

I confirmed that the contribution is

1. Contains No Cryptography
2. Is Developed from Scratch (without incorporating content from elsewhere)
3. Is 100% Project License Code

Subscribed devices do not receive messages

Hello, currently a team of students (including myself) are trying to create a thread based IoT network connected to AWS for a class project. We are trying to use RSMB to broker messages, because AWS can only understand MQTT packets. Once the border router receives MQTT packets from AWS, it takes the payload and sends it as a MQTT-SN packet to the broker. The issue is that the end devices, which are nordic microcontrollers, are not reading these packets when they are subscribed to the proper channel. Does anybody have any idea what we can do differently or somebody we can contact that is a subject matter expert?

RSMB build fixes on OS X

migrated from Bugzilla #422167
status ASSIGNED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• osx-build.diff (ID 237591)

On 2013-11-20 11:48:58 -0500, Andy Piper wrote:

Created attachment 237591
patches to Broker.c and Socket.c

Couple of minor defines around some build issues on OS X (specifically 10.9) with deprecated headers etc.

On 2013-11-21 04:31:34 -0500, Jan-Piet Mens wrote:

On Darwin Kernel Version 12.5.0 I also had to comment out line 284 in Clients.h
Clients.h:284: error: too many #pragma options align=reset

On 2013-11-21 04:34:39 -0500, Andy Piper wrote:

(In reply to Jan-Piet Mens from comment # 1)

On Darwin Kernel Version 12.5.0 I also had to comment out line 284 in
Clients.h
Clients.h:284: error: too many #pragma options align=reset

Interesting, I don't get that error (using the default makefile). I get a bunch of warnings. 10.9 has Darwin kernel 13.0.0.

On 2013-11-24 11:23:05 -0500, Nicholas Humfrey wrote:

Thanks for the patch Andy :)

I am also seeing the the same error as Jan-Piet:

Clients.h:553: error: too many #pragma options align=reset
In file included from Bridge.h:21,
from Broker.h:23,
from Broker.c:65:

Commenting out line 553 (after applying Andy's patch) of Clients.h fixes it.

OS: Mac OS 10.8.5 (Darwin Kernel Version 12.5.0)
GCC: gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Note that Mac OS X doesn't use gcc anymore by default but the Makefile specifically uses gcc.

On 2014-02-18 10:57:20 -0500, Andy Piper wrote:

bump any interest in getting this fixed? I just hit the same things on a fresh clone / build.

On 2014-02-18 11:15:00 -0500, Jan-Piet Mens wrote:

Yes, please! Happened to me a few days ago too. (sigh)

On 2014-02-18 16:10:01 -0500, Roger Light wrote:

Andy, could you modify the patch to combine the two if defines in Broker.c into an if/elif? It makes sense to group them together as they are related. I think the same change needs to go into amqtdd/src/Broker.c as well.

If you do that you can then either update the patch here, state here that you've complied with the Certificate of Origin and I'll commit the patch, or possibly easier if you do your own commit on a clone on github, following the commit message format as described[1] and point to it here then I'll pull and push.

I couldn't see the lines mentioned in Clients.h. Any hints?

On 2014-02-26 17:36:59 -0500, Ian Craggs wrote:

Yes, I want to fix it. I have to bring out my Mac - I've been busy with the MQTT test material and other stuff...

Broker requires a client ID

If persistence is true on RSMB a MQTT-SN client don't receive messages published before its connection

migrated from Bugzilla #430828
status ASSIGNED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• all.patch (ID 241069)
• all_plus_infligth_fix.patch (ID 241099)

On 2014-03-20 15:17:57 -0400, Daniel Nascimento wrote:

Steps to reproduce:
1- Connect if a MQTT-SN client in a qos=1 topic
2- Shutdown RSMB with persistence true
3- Start RSMB with persistence true
4- Publish some messages in that topic that the client was connected
5- Reconnect the client

The client won't receive that messages published to it when it reconnects.

On 2014-03-20 15:19:53 -0400, Daniel Nascimento wrote:

Created attachment 241069
This patch includes fixes for all bugs related to this feature

Include fixes to:

430788

430737

430733

On 2014-03-20 18:11:14 -0400, Ian Craggs wrote:

This is true. And working as originally intended, for which you can blame Andy Stanford-Clark and Dave Conway-Jones who insisted that persistence was not necessary for a small edge of network server! I only included functions that were asked for.

Thanks for the patch. I'll be interested to see what approach you've taken - when the messages are saved. Other persistence data is only saved periodically to disk (autosave) and at shutdown.

On 2014-03-20 18:39:18 -0400, Daniel Nascimento wrote:

For now I'm working in keep the MQTT-SN on a par with MQTT implementation. I'm using RSMB as a MQTT-SN gateway to comunicate with a ActiveMQ server. So I not implemented messages persistence yet, I'm just using the subscribe persistence already implemented.

Since RSMB deliver Ack's to ActiveMQ I'll need to persist messages to grant that messages will not be lost. So I the next days i'll do it.

I'm planning to persist only the messages that will be queued, and probably I'll use sqlite for this. If you think in a another aproach if grather chance to go upstream I'm interested in listen so it can driven my development.

On 2014-03-20 20:54:29 -0400, Ian Craggs wrote:

Daniel, I'm very happy that you are using MQTT-SN in RSMB!

However, while I'm happy to fix bugs in the MQTT-SN implementation, I am hesitant to rush into to adding message persistence into RSMB. The notional plan I had in mind was to work with Roger to add MQTT-SN support into Mosquitto, which already has message persistence, rather than reimplement this function in RSMB.

The longer term goal is to have one implementation covering all the function we need. I realize Roger hasn't contributed the Mosquitto code to Eclipse yet, but that is going to happen soon.

I wouldn't want any persistence to require sqllite. Roger already moved away from that in Mosquitto. It's ok to have a pluggable persistence interface, and plug sqllite into that. My preferred solution (next to using Mosquitto) is to have a key-value pair persistence interface (like the Paho C client) into which various providers can be plugged.

Currently I've just started working on a C MQTT-SN client (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/) - I would like to finish that first so I can use it for testing MQTT-SN in RSMB for one thing.

I hope we can find a way to work together to find the best solution for you.

On 2014-03-21 09:21:44 -0400, Daniel Nascimento wrote:

Created attachment 241099
Last patch don't deliver all messages if queued messages > max_inflight_messages

If a client has more queued messages than the max_inflight_massages value, messages are not delivered.

This patch change retry method to choose the right queue to look for not delivered messages.

On 2014-03-21 09:41:48 -0400, Daniel Nascimento wrote:

It's not clear to me if the RSMB project will be deprecated in favour of a future version of mosquitto, implementing MQTT-SN. If that is the case, IMHO, the better approach is just to fix bugs on RSMB and keep all new features for mosquitto.

So I'm not sure if the persistence code that I'll wrote will be desirable for RSMB project (I'll base it in the Paho C client implementation that you suggested, thanks).

For testing RSMB I'm using a modified version of mqtt_sn_tools that work like mosquitto_sub/mosquitto_pub, so I can compare the RSMB behaviour with MQTT and MQTT-SN.

Will messages of MQTT-SN clients not published

I noticed my MQTT clients' wills were getting published but not MQTT-SN clients. Upon some investigation into the code I found MQTTProtocol_keepalive in MQTTProtocolClient.c which is responsible for closing timed out client sessions with the send_will flag set. It iterates through bstate->clients and checks whether client->protocol == PROTOCOL_MQTTS. However that is always going to be false because the MQTT-SN clients are not in bstate->clients, they are in bstate->mqtts_clients.

What dose AMQTDD stands for in RSMB?

What dose AMQTDD stands for in RSMB?

When a client reconnects it don't receive queued messages

migrated from Bugzilla #430788
status UNCONFIRMED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• mqttsn_existing_client_fix.patch (ID 241054)
• mqttsn_remove_outbound_rule.patch (ID 241055)

On 2014-03-20 08:24:30 -0400, Daniel Nascimento wrote:

Steps to reproduce:
1- Connects a MQTT-SN client and subscribe in a topic
2- Disconnect it
3- Post some messages in the topic that the client was subcribed
4- Reconnect the client

After applying the patch for bug # 430733 and # 430737 the RSMB will queue messages for the client, but it don't deliver them.

On 2014-03-20 08:25:24 -0400, Daniel Nascimento wrote:

Created attachment 241054
Fix the rule to determine a pre existing client

On 2014-03-20 08:27:15 -0400, Daniel Nascimento wrote:

Created attachment 241055
Remove a rule restricting the deliver for a client if a outbound greater than zero

I didn't understand this rule so I don't know commenting it is the right fix.

On 2014-03-20 09:29:51 -0400, Daniel Nascimento wrote:

If the broker is running with "persistence true" these patches won't fix the problem.

Compile for MacOSX 10.8.5

migrated from Bugzilla #456087
status UNCONFIRMED severity enhancement in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2014-12-23 10:38:26 -0500, Laurent Roger wrote:

In order to compile rsmb in a MacOSX 10.8.5 / XCode 5.1.1, here are the suggested modifications :

• Makefile, force GCC definition (remove ifndef)

GCC = gcc -D_XOPEN_SOURCE=600 -D_DARWIN_C_SOURCE

• Socket.h, add these lines at the end :

typedef unsigned int u_int;
typedef unsigned long u_long;
typedef unsigned char u_char;

ifndef IPV6_ADD_MEMBERSHIP

define IPV6_ADD_MEMBERSHIP IPV6_JOIN_GROUP

define IPV6_DROP_MEMBERSHIP IPV6_LEAVE_GROUP

endif

You can then make and launch :
./broker
20141223 163728.187 CWNAN9999I Really Small Message Broker
20141223 163728.187 CWNAN9998I Part of Project Mosquitto in Eclipse
(http://projects.eclipse.org/projects/technology.mosquitto)
20141223 163728.187 CWNAN0053I Version 1.3.0.2, Dec 23 2014 16:20:11
20141223 163728.187 CWNAN0054I Features included: bridge
20141223 163728.187 CWNAN9993I Authors: Ian Craggs ([email protected]), Nicholas O'Leary
20141223 163728.187 CWNAN0014I MQTT protocol starting, listening on port 1883

:)

MQTT-SN not working with IPv6

migrated from Bugzilla #434748
status RESOLVED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2014-05-13 09:44:16 -0400, Ian Craggs wrote:

When an MQTT-SN listener is set to use IPv6 incoming packets are read, but outgoing packets do not reach their destination. Reported by: Adam Renner

https://groups.google.com/forum/#!topic/mqtt/ad7ZKP6Ue74

On 2014-05-13 09:50:32 -0400, Ian Craggs wrote:

Fixed, at least on my Linux testing...

How to enable/disable RSMB for MQTT thru web socket

How to enable/disable RSMB for MQTT thru web socket? I am trying to implement Eclipse Paho Javascript library but I am not able to connect RSMB Eclipse Paho mqttws31

Python MQTT-SN client crashes with qos = -1

migrated from Bugzilla #463425
status UNCONFIRMED severity normal in component RSMB for 1.4
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2015-03-30 05:57:28 -0400, Joao Mauricio wrote:

When QoS is set to -1:

aclient.connect()
aclient.register(�jkjkjkjkj�)
aclient.publish(1, �aaaa�, -1)

Python MQTT-SN client crashes with the following error:

Traceback (most recent call last):
File �./MQTTSNregister.py�, line 33, in
aclient.publish(1, �aaaa�, -1)
File �/root/rsmb/rsmb/src/MQTTSClient/Python/MQTTSNclient.py�, line 180, in publish
self.sock.send(publish.pack())
File �/root/rsmb/rsmb/src/MQTTSClient/Python/MQTTSN.py�, line 491, in pack
buffer = self.Flags.pack()
File �/root/rsmb/rsmb/src/MQTTSClient/Python/MQTTSN.py�, line 107, in pack
(self.Will << 3) | (self.CleanSession << 2) | self.TopicIdType )
ValueError: chr() arg not in range(256)

However, using:

aclient.connect()
aclient.register(�jkjkjkjkj�)
aclient.publish(1, �aaaa�, 0)

everything works as expected.

Crash when publishing an unregistered MQTT-SN topic

migrated from Bugzilla #424692
status RESOLVED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• file_424692.txt (ID 238579)

On 2013-12-27 08:22:49 -0500, John Donovan wrote:

Created attachment 238579
Diff of NULL pointer exception fix.

When a client connects to the MQTT-SN broker and publishes an unregistered topic ID, the broker crashes.

In MQTTSProtocol_handlePublishers(), the topic name is searched for by its ID with the function MQTTSProtocol_getRegisteredTopicName(). If the ID cannot be found, MQTTSProtocol_getRegisteredTopicName() returns NULL. MQTTSProtocol_handlePublishers() doesn't check for NULL and tries to call strlen() on the NULL pointer which crashes.

To fix, I have put a NULL pointer check around the calls to strlen() and strcpy(), which means topicName is NULL, and is caught in the normal program flow.

I have supplied a diff with the necessary changes.

On 2013-12-29 06:31:31 -0500, Ian Craggs wrote:

Thanks. Registered topics are one of the two functions not yet implemented, but we should protect against this in any case.

On 2014-01-21 06:18:30 -0500, Ian Craggs wrote:

Fixed in master branch.

Need a broker/server instalation to support MQTT-SN (in windows 8.1)

migrated from Bugzilla #474509
status UNCONFIRMED severity normal in component RSMB for 1.4
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2015-08-07 11:16:08 -0400, Syed Shah wrote:

Trying to connect MQTT-SN Client to a server. Mosquitto do not work as it only support TCP. MQTT-SN is on UDP.

I need a broker software that support MQTT-SN client for publish subscribe.

Build warnings on OS X

migrated from Bugzilla #428455
status ASSIGNED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• warning-fixes.diff (ID 243505)

On 2014-02-18 11:17:19 -0500, Andy Piper wrote:

After applying the patch attached to # 422167 on OS X 10.9, the following warnings remain when the broker is compiled:

gcc -Wall -s -Os _.c -o broker
Broker.c:510:34: warning: format specifies type 'long' but the argument has type 'int' [-Wformat]
sprintf(&ptr[26], ".%.3ld.dmp", ts.tv_usec / 1000);
~~~~~ ^~~~~~~~~~~~~~~~~
%.3d
/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
__builtin___sprintf_chk (str, 0, __darwin_obsz(str), VA_ARGS)
^
1 warning generated.
ld: warning: option -s is obsolete and being ignored
gcc -Wall -ggdb *.c -o broker_dbg
Broker.c:510:34: warning: format specifies type 'long' but the argument has type 'int' [-Wformat]
sprintf(&ptr[26], ".%.3ld.dmp", ts.tv_usec / 1000);
~~~~~ ^~~~~~~~~~~~~~~~~
%.3d
/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
__builtin___sprintf_chk (str, 0, __darwin_obsz(str), VA_ARGS)
^
1 warning generated.
gcc -DMQTTS -Wall -s -Os *.c -o broker_mqtts
Broker.c:510:34: warning: format specifies type 'long' but the argument has type 'int' [-Wformat]
sprintf(&ptr[26], ".%.3ld.dmp", ts.tv_usec / 1000);
~~~~~ ^~~~~~~~~~~~~~~~~
%.3d
/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
__builtin___sprintf_chk (str, 0, _darwin_obsz(str), VA_ARGS)
^
1 warning generated.
MQTTSPacket.c:405:8: warning: unused variable 'enddata' [-Wunused-variable]
char enddata = &data[header.len - 2];
^
1 warning generated.
ld: warning: option -s is obsolete and being ignored

On 2014-02-26 17:38:37 -0500, Ian Craggs wrote:

I'll try and get the Mac out soon!

On 2014-05-26 16:54:49 -0400, Nicholas Humfrey wrote:

Created attachment 243505
Patch to fix a couple of warnings

Attached a patch that fixes a couple of the warnings

Sample configuration file contains invalid token

When using the sample configuration file

# Uncomment this to show you packets being sent and received
#trace_output protocol

# Normal MQTT listener
listener 1883 INADDR_ANY
ipv6 true

# MQTT-SN listener
listener 1883 INADDR_ANY mqtts
ipv6 true

(found in the README.md file), the broker application spits out the following error message:

Unrecognized configuration value mqtts on line number 9

What is the purpose of broker_timestamp_eye and broker_version_eye?

Hello,

I have been going through fixing compiler warnings and found these unused variables?
In Broker.c / main():

static char* broker_version_eye = NULL;
static char* broker_timestamp_eye = NULL;
broker_timestamp_eye = "RSMB_Timestamp " BUILD_TIMESTAMP;
broker_version_eye = "RSMB_Version " BROKER_VERSION; 

Is it used for some kind of symbol extraction/debugging voodoo?

nick.

Errors after MQTT-SN client reconnection

migrated from Bugzilla #462795
status UNCONFIRMED severity major in component RSMB for 1.4
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2015-03-22 14:07:00 -0400, Ivan Makeev wrote:

When MQTT-SN client reconnects with same client ID, it gets "transport endpoint not connected" error on any packet sent after CONNECT. Example from RSMB log:

20150322 185455.213 CWNAN0034I Duplicate connection attempt received for client identifier "ENV-02124B00040EF660" from address 127.0.0.1:54113, ending oldest connection
20150322 185455.213 134517200 127.0.0.1:54113 ENV-02124B00040EF660 -> MQTT-S CONNACK returncode 0 (0)
20150322 185455.213 CWNAN0000I Client connected to udp port 1882 from ENV-02124B00040EF660 (127.0.0.1:54113)
20150322 185510.128 CWNAN0075W Socket error 107 (Transport endpoint is not connected) in getpeername for socket 3
20150322 185510.128 CWNAN0023W Connect was not first packet on socket 3, peer address unknown; got SUBSCRIBE

Presumbly, the error caused by not updating the clients table properly.
In MQTTSProtocol.c, function MQTTSProtocol_handleConnects contains block for such a case under
/* have to remove and re-add client so it is in the right order for new socket */
but condition (client->socket != sock) will always evaluate to false as statement
client->socket = sock;
goes few lines before. Seems full address should be compared here before new socket value is assigned. Moreover, inside this block the statement:
TreeRemoveKeyIndex(bstate->mqtts_clients, &client->socket, 0);
should be presumably changed to
TreeRemoveKeyIndex(bstate->mqtts_clients, client->addr, 0);
as index in the tree is over full address, not just socket.

Error on make: multiple definition of '...'

I don't know if it occurs only for newer gcc versions (I tried it for gcc-9 and gcc-10), but when I tried installing it, the make command outputted 'multiple definition' error for the variables 'Log_levels' and 'bstate'.

The solution that worked for me is doing the following changes in src folder:

• File: Log.h (line:38)
  Instead of enum { ... }Log_levels; ---> enum Log_levels{ ... };

• Files: MQTTSProtocol.c (line:118), Protocol.c (line:44), Users.c (line:36)
  Instead of BrokerStates* bstate; ---> extern BrokerStates* bstate;

If a client reconnect its clientid is not cleaned correctly

migrated from Bugzilla #430733
status RESOLVED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• FFDC.CWNAN.20140319.174135.548.dmp (ID 241025)
• mqttsn_reconnect.patch (ID 241026)

On 2014-03-19 17:08:31 -0400, Daniel Nascimento wrote:

Created attachment 241025
RSMB Dump

Steps to reproduce:
1- Connect a MQTT-SN client in RSMB
2- Subscribe it in a certain topic
3- Disconnect it from RSMB
4- Reconnect this client with the same ClientID
5- Close RSMB

Doing this the RSMB will fail to clean the Heap memory allocated to store the ClientID in subscribe engine.

On 2014-03-19 17:10:45 -0400, Daniel Nascimento wrote:

Created attachment 241026
Patch to fix this bug

On 2014-07-04 10:56:44 -0400, Ian Craggs wrote:

Thanks for the patch. Added to the master branch.

RSMB configuration file

Hello, I am trying to use the RSMB on virtualbox (Ubuntu as guest & windows as host because I couldn't run it with cygwin). When configuring the broker as mentioned by the tutorial, I keep getting "connect for bridge local_bridge_to_mosquitto address 127.0.0.1:1888 failed with TCP error code111"
Am I getting this error because I am using a virtual machine?
I would be grateful if someone can explain to me how to set the IP addresses in the configuration or give me a hint how to solve this.
Thanks in advance
The configuration file currently:
#to trace the output
trace_output protocol

#normal MQTT listener
listener 1887 INADDR_ANY mqtt

#MQTT-SN listener
listener 1886 INADDR_ANY mqtts

#MQTT-S outgoing local bridge
connection local_bridge_to_mosquitto
address 127.0.0.1:1888
topic #out

#MQTT-S outgoing remote bridge
connection remote_bridge_to_mosquitto
address 192.168.1.104:1889
topic #out

Broker requires an IP address for bridge not a server name

When a client reconnects it don't receive new messages

migrated from Bugzilla #430737
status RESOLVED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• mqttsn_reconnect_delivery.patch (ID 241027)

On 2014-03-19 17:30:46 -0400, Daniel Nascimento wrote:

Steps to reproduce:
1- Connect a MQTT-SN client in RSMB
2- Disconnect it from RSMB
3- Connect it again with the same ClientID

Messages from the topic that this client is subscribed are not delivered to it anymore.

On 2014-03-19 17:34:25 -0400, Daniel Nascimento wrote:

Created attachment 241027
Patch to fix this bug

On 2014-07-03 11:19:57 -0400, Ian Craggs wrote:

Fixed in master. Thanks

Unable to connect to remote broker

Hello, I am using RSMB on VirtualBox(Ubuntu) and i was trying to connect to CloudMQTT online broker. However, the connection keeps timing out. Can you please help me with this?
My config file:

#to trace the output
trace_output protocol

#normal MQTT listener
listener 1885 INADDR_ANY mqtt

#MQTT-SN listener
listener 1887 INADDR_ANY mqtts

#MQTT outgoing remote bridge
#connection cloudmqtt
#address mXX.cloudmqtt.com:portno
#username XXX
#password XXX
#try_private false
#start_type automatic
#topic datetime in
#topic time out

This was the output:
20180528 165618.691 CWNAN0124I Starting bridge connection cloudmqtt
20180528 170913.128 CWNAN0128I TCP connect timeout for bridge connection cloudmqtt

Update: It works when I put the IP address instead of the server name

MQTT-SN broker forgets published topics

migrated from Bugzilla #424704
status ASSIGNED severity normal in component RSMB for ---
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

Original attachment names and IDs:

• 0001-Fix-of-Bug-424704-MQTT-SN-broker-forgets-published-t.patch (ID 251381)

On 2013-12-27 13:57:17 -0500, John Donovan wrote:

According to the MQTT-SN spec, if a client goes to sleep by sending DISCONNECT with a timeout, and it reconnects within that period, the broker should remember all the registered topics for that client so it doesn't have to re-register.
Mosquitto/RSMB doesn't do that as can be seen in MQTTSProtocol.c:442

On 2013-12-29 06:19:26 -0500, Ian Craggs wrote:

Yes. Sleeping clients is one of the two functions not yet implemented. The other being the ability to pre-register topics. I'll leave this bug open pending the addition of the function to support sleeping clients.

On 2015-03-07 07:25:41 -0500, Michal Foksa wrote:

Created attachment 251381
Fix of Bug 424704 - If duration in disconnect request is not zero, client registrations are kept.

Here you are a fix: if duration in disconnect request is not zero, client registrations are kept.