emqx / emqx-sn Goto Github PK

View Code? Open in Web Editor NEW

29.0 29.0 20.0 816 KB

EMQX MQTT-SN Gateway

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

License: Apache License 2.0

Makefile 2.41% Erlang 73.63% Python 0.78% C 23.17%

mqtt mqtt-sn

emqx-sn's Introduction

emqx-sn

EMQX MQTT-SN Gateway.

Configure Plugin

File: etc/emqx_sn.conf

## The UDP port which emq-sn is listening on.
##
## Value: IP:Port | Port
##
## Examples: 1884, 127.0.0.1:1884, ::1:1884
mqtt.sn.port = 1884

## The duration(seconds) that emq-sn broadcast ADVERTISE message through.
##
## Value: Second
mqtt.sn.advertise_duration = 900

## The MQTT-SN Gateway id in ADVERTISE message.
##
## Value: Number
mqtt.sn.gateway_id = 1

## To control whether write statistics data into ETS table for dashbord to read.
##
## Value: on | off
mqtt.sn.enable_stats = off

## To control whether accept and process the received publish message with qos=-1.
##
## Value: on | off
mqtt.sn.enable_qos3 = off

## The pre-defined topic name corresponding to the pre-defined topic id of N.
## Note that the pre-defined topic id of 0 is reserved.
mqtt.sn.predefined.topic.0 = reserved
mqtt.sn.predefined.topic.1 = /predefined/topic/name/hello
mqtt.sn.predefined.topic.2 = /predefined/topic/name/nice

## Default username for MQTT-SN. This parameter is optional. If specified,
## emq-sn will connect EMQ core with this username. It is useful if any auth
## plug-in is enabled.
##
## Value: String
mqtt.sn.username = mqtt_sn_user

## This parameter is optional. Pair with username above.
##
## Value: String
mqtt.sn.password = abc

mqtt.sn.port
- The UDP port which emqx-sn is listening on.
mqtt.sn.advertise_duration
- The duration(seconds) that emqx-sn broadcast ADVERTISE message through.
mqtt.sn.gateway_id
- Gateway id in ADVERTISE message.
mqtt.sn.enable_stats
- To control whether write statistics data into ETS table for dashbord to read.
mqtt.sn.enable_qos3
- To control whether accept and process the received publish message with qos=-1.
mqtt.sn.predefined.topic.N
- The pre-defined topic name corresponding to the pre-defined topic id of N. Note that the pre-defined topic id of 0 is reserved.
mqtt.sn.username
- This parameter is optional. If specified, emqx-sn will connect EMQX core with this username. It is useful if any auth plug-in is enabled.
mqtt.sn.password
- This parameter is optional. Pair with username above.

Load Plugin

./bin/emqx_ctl plugins load emqx_sn

Client

NOTE

Topic ID is per-client, and will be cleared if client disconnected with broker or keepalive failure is detected in broker.
Please register your topics again each time connected with broker.
If your udp socket(mqtt-sn client) has successfully connected to broker, don't try to send another CONNECT on this socket again, which will lead to confusing behaviour. If you want to start from beging, please do as following:
- destroy your present socket and create a new socket to connect again
- or send DISCONNECT on the same socket and connect again.

Library

sleeping device

PINGREQ must have a ClientId which is identical to the one in CONNECT message. Without ClientId, emqx-sn will ignore such PINGREQ.

pre-defined topics

The mapping of a pre-defined topic id and topic name should be known inadvance by both client's application and gateway. We define this mapping info in emqx_sn.conf file, and which shall be kept equivalent in all client's side.

License

Apache License Version 2.0

Author

EMQX Team.

emqx-sn's People

Contributors

Stargazers

Watchers

Forkers

turtledeng grutabow ty1970s fayer1986 harunoni cyqsign tigercl allanli0508 tradingtrace 350984267 idau2012 zmstone uttaravadina ygyangguang 10088 igit-cn fastdgiot accumulation34 lx6317648

emqx-sn's Issues

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:qos -1,it is topic length
00 00: packet id
68 65 6C 6C 6F : hello
74 65 73 74 :test

14:42:21.648 [info] MQTT-SN(172.21.128.54:54279): RECV "mqtt_sn_message SN_PUBLISH, "mqtt_sn_flags{dup=false, qos=3, retain=false, will=undefined, clean_session=undefined, topic_id_type=0}", TopicId=5, MsgId=0, Payload=<<104,101,108,108,111,116,101,115,116>>" at state connected
14:42:21.648 [debug] MQTT-SN(172.21.128.54:54279): Receive a publish with Qos=-1

So I find problem that Emq-sn parse Topic len(00 05) into TopicId(5).And payload is changed to "hellotest"(topic+payload).This Cause Client B can not receive any message(topic is hello).Emq-sn may parse wrong.

Serial port support

I am wondering how can I connect the sn gateway to a serial port device ?

Shutdown due to idle timeout

Using emqx version 3.0 with the MQTT-SN plugin i get the following error messages:

2019-04-24 07:47:21.452 [error] MQTT-SN(127.0.0.1:40289): shutdown due to idle_timeout
2019-04-24 07:47:21.452 [error] MQTT-SN(172.17.0.2:40289): shutdown due to idle_timeout
2019-04-24 07:47:21.453 [error] MQTT-SN(172.17.0.1:38892): shutdown due to idle_timeout
2019-04-24 07:47:36.453 [error] MQTT-SN(127.0.0.1:40289): shutdown due to idle_timeout
2019-04-24 07:47:36.454 [error] MQTT-SN(172.17.0.2:40289): shutdown due to idle_timeout
2019-04-24 07:47:36.454 [error] MQTT-SN(172.17.0.1:38892): shutdown due to idle_timeout

Any idea what might be the problem?

QoS -1 Not Working

Hello,

I am using MQTT-SN-Tools as my MQTT-SN client.

When I publish messages with QoS -1 to EMQ X broker with EMQ X SN plugin, the subscribing client is not receiving the message.
I have set mqtt.sn.enable_stats = on in the configuration file and confirmed that the subscribing PC is indeed receiving the packet, but EMQ X SN plugin doesn't seem to process it.

When I try publishing a message with QoS 0 or 1, the subscribing client is able to receive it.

Any help would be greatly appreciated.

QoS granted on SUBACK is ignored

When a client SUBSCRIBE to a topic, it can specify a QoS, and the gateway replies with a SUBACK specifying the granted QoS. However, the granted QoS for a subscribed topic is ignored by the gateway afterwards. The QoS of the subscribed topic at any given time seems to be determined by the QoS set on the PUBLISH message by e.g. another client.

UNSUBSCRIBE without a payload disconnects the client

Due to an error, a connected client sent an UNSUBSCRIBE without a payload to the MQTT-SN gateway. I notice that the client is disconnected immediately after without any notification.

Options for transparent and aggregate sn gateway

Does emqx-sn has option to enable gateway as transparent or aggregate as per MQTT-SN protocol spec?

mqtt-sn Gateway not working

I played around with the emq_sn plugin. I am trying to publish some messages using mqtt-sn-tools.

./mqtt-sn-pub -d -d -d -h 127.0.0.1 -p 1884 -q 0 -r -t world -m hello

However as the below output shows, i do not receive meaningful topic id:

2017-04-11 13:37:25 DEBUG Debug level is: 3.
2017-04-11 13:37:25 DEBUG Connecting...
2017-04-11 13:37:25 DEBUG Sending CONNECT packet...
2017-04-11 13:37:25 DEBUG Sending  24 bytes. Type=CONNECT on Socket: 3.
2017-04-11 13:37:25 DEBUG waiting for packet...
2017-04-11 13:37:25 DEBUG Received  3 bytes from 127.0.0.1:1884. Type=CONNACK on Socket: 3
2017-04-11 13:37:25 DEBUG CONNACK return code: 0x00
2017-04-11 13:37:25 DEBUG Sending REGISTER packet...
2017-04-11 13:37:25 DEBUG Sending  11 bytes. Type=REGISTER on Socket: 3.
2017-04-11 13:37:25 DEBUG waiting for packet...
2017-04-11 13:37:25 DEBUG Received  7 bytes from 127.0.0.1:1884. Type=REGACK on Socket: 3
2017-04-11 13:37:25 DEBUG REGACK return code: 0x00
2017-04-11 13:37:25 DEBUG REGACK topic id: 0x0000
2017-04-11 13:37:25 DEBUG Sending PUBLISH packet...
2017-04-11 13:37:25 DEBUG Sending  12 bytes. Type=PUBLISH on Socket: 3.
2017-04-11 13:37:25 DEBUG Disconnecting...
2017-04-11 13:37:25 DEBUG Sending DISCONNECT packet...
2017-04-11 13:37:25 DEBUG Sending   2 bytes. Type=DISCONNECT on Socket: 3.

Subscribing to a topic does also not work for me. I get a topic id that is unequal to 0x0000. So far so good. But no packages arrive at the subscriber:

mqtt-sn-sub -d -d -d -h 127.0.0.1 -p 1884 -V -t world

2017-04-11 13:44:47 DEBUG Verbose level is: 2.
2017-04-11 13:44:47 DEBUG Network timeout is: 5 seconds.
2017-04-11 13:44:47 DEBUG Connecting...
2017-04-11 13:44:47 DEBUG Sending CONNECT packet...
2017-04-11 13:44:47 DEBUG Sending  24 bytes. Type=CONNECT on Socket: 3.
2017-04-11 13:44:47 DEBUG waiting for packet...
2017-04-11 13:44:47 DEBUG Received  3 bytes from 127.0.0.1:1884. Type=CONNACK on Socket: 3
2017-04-11 13:44:47 DEBUG CONNACK return code: 0x00
2017-04-11 13:44:47 DEBUG Sending SUBSCRIBE packet...
2017-04-11 13:44:47 DEBUG Sending  10 bytes. Type=SUBSCRIBE on Socket: 3.
2017-04-11 13:44:47 DEBUG waiting for packet...
2017-04-11 13:44:47 DEBUG Received  8 bytes from 127.0.0.1:1884. Type=SUBACK on Socket: 3
2017-04-11 13:44:47 DEBUG SUBACK return code: 0x00
2017-04-11 13:44:47 DEBUG SUBACK topic id: 0x0001
2017-04-11 13:44:47 DEBUG Registering topic 0x0001: world
2017-04-11 13:44:57 DEBUG Sending PINGREQ packet...
2017-04-11 13:44:57 DEBUG Sending   2 bytes. Type=PINGREQ on Socket: 3.
2017-04-11 13:44:57 DEBUG waiting for packet...
2017-04-11 13:44:57 DEBUG Received  2 bytes from 127.0.0.1:1884. Type=PINGRESP on Socket: 3
2017-04-11 13:45:07 DEBUG Sending PINGREQ packet...
2017-04-11 13:45:07 DEBUG Sending   2 bytes. Type=PINGREQ on Socket: 3.
2017-04-11 13:45:17 ERROR Keep alive error: timed out while waiting for a PUBLISH from gateway.

Even though i can see the client in the webinterface of the EMQ broker with the correct timeout set to 10, the client times out after the first successful PINGREQ.

Any idea?

Empty ClintId on connect

Emqx 4.3.7 by helm installer

2021-08-31T12:13:29.538799+00:00 [debug] 10.42.0.0:39055 [MQTT] RECV <<16,48,0,4,77,81,84,84,5,192,0,60,0,0,0,0,9,103,114,...>>
2021-08-31T12:13:29.539098+00:00 [debug] 10.42.0.0:39055 [MQTT] RECV CONNECT(Q0, R0, D0, ClientId=, ProtoName=MQTT, ProtoVsn=5, CleanStart=false, KeepAlive=60, Username=greatuser, Password=******)
2021-08-31T12:13:29.539288+00:00 [debug] 10.42.0.0:39055 [MQTT] SEND CONNACK(Q0, R0, D0, AckFlags=0, ReasonCode=133)
2021-08-31T12:13:29.539566+00:00 [info] 10.42.0.0:39055 file: emqx_connection.erl, line: 520, mfa: {emqx_connection,terminate,2}, msg: terminate, pid: <0.3780.0>, reason: {shutdown,client_identifier_not_valid}

Support of sleeping clients

In the MQTT-SN protocol specification (Version 1.2), Section 6.14, the support of sleeping clients is described. This is currently not implemented on emq-sn (emqttd-2.2-beta.2). When could I expect this feature?

Forward to mqtt server

Hi -

MQTT Newbie here. I have a rails server setup that I want to subscribe to my emq MQTT server to listen for certain topics. Unfortunately I cant seem to connect to UDP to listen to the MQTT-SN server. Im wondering if it's possible to forward any incoming messages that the MQTT-SN server receives to the EMQ MQTT server so that it can then publish them for my rails app to subscribe to?

We have an IoT device that is publishing to the MQTT-SN server via UDP, which is why we are using MQTT-SN, but need the server to be able to subscribe to the messages.

Thanks,

Josh

connection would be destroyed if mqtt-sn client send a 2nd CONNECT in connected state.

if mqtt-sn client send a 2nd CONNECT in connected state,
the client has no CONNACK response, and connection is gone from connection list

version: 3.1.2 and 3.2.0-rc

Subsequent CONNECTs ignored by gateway

After the gateway receives a CONNECT from a client, further CONNECTs from the same clients are ignored by the gateway, unless the gateway receives a DISCONNECTs from said client.

The gateway should start a new session every time it receives a CONNECT from a client. There are at least three good reasons to do this:

if the clients miss the CONNACK from the gateway, the client will try again (send one more CONNECT). Currently, this second (or any further) attempt to connect has no effect, thus making impossible for the client to connect, and making it hard for the client to know if the gateway is alive.
There are cases on which the client might not know if a connection is already open (e.g. after a unexpected reset of the client). It is then good for a CONNECT to always return a CONNACK and start a new session.
if the client wants to change the connection parameters of an existing connection (e.g. change the keep alive timer), it should be able to do so without disconnecting in advance.

I obseved that RSMB always return a CONNACK after receiving a CONNECT from a client, independently of if the client already has an open connection. I think this is the right behaviour, considering the three points mentioned above.

Setting the port to ::1:2000 causes error

When setting the port to ::1:2000 (as mentioned in the comment) emqttd exits with the following error message.

15:13:40.661 [error] Error generating configuration in phase transform_datatypes
15:13:40.661 [error] Error transforming datatype for: mqtt.sn.port
15:13:40.661 [error] "::1:20000" cannot be converted to a(n) integer

Is setting the port to ::1:xxxx even required when trying to get IPv6 only clients to connect with the MQTT-SN bridge?
Thanks in advance!

Failure to accept Sn messages with v3 beta

Lager event handler error_logger_lager_h exited with reason {'EXIT',{{case_clause,[<0.1677.0>,{undefined,undefined},error,{'function not exported',{emqx_protocol,init,3}},undefined,[{emqx_sn_gateway,init,1,[{file,"src/emqx_sn_gateway.erl"},{line,103}]},{gen_statem,init_it,6,[{file,"gen_statem.erl"},{line,697}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,249}]}]]},[{error_logger_lager_h,log_event,2,[{file,"src/error_logger_lager_h.erl"},{line,206}]},{gen_event,server_update,4,[{file,"gen_event.erl"},{line,577}]},{gen_event,server_notify,...},...]}}
([email protected])1> ^C

Forwarder encapsulation

Hi.

I need to use MQTT-SN implementation over Digimesh network. I'm thinking on use and build digimesh forwarder to emqx udp port. At MQTT-SN specs, point 5.5, i have read there is special encapsulation for forwarder packets.

Is this encapsulation spec supported by this plugin? I was reading plugin information but I didn't find anything related.

Thanks in advance. Best regards.

CONNACK is not always sent to the client

I found a strange behaviour on the MQTT-SN plugin. If a client sends a CONNECT request twice in a row, a CONNACK is send every other time (see attached file). For example:
CONNECT (client -> gateway)
CONNACK (gateway -> client)
CONNECT (client -> gateway)
(here the expected CONNACK is not sent)
CONNECT (client -> gateway)
CONNACK (gateway -> client)

Note that this only happens if the client uses the same source port (9977 in the attached file).

SEARCHGW should always be answered by gateway

Hi.

I'm developing wireless sensor network through Xbee, so I have developed xbee-udp forwarder (without forwarder encapsulation 0xFE, at the moment) to bridge xbee with emqx broker. I have problems if a connected node sends SEARCHGW packet. An error like below is launched:

23:52:36.533 [error] MQTT-SN(192.168.1.38:63251): asleep UNEXPECTED Event: {mqtt_sn_message,1,0}

23:56:13.700 [error] MQTT-SN(192.168.1.38:63251): connected UNEXPECTED Event: {mqtt_sn_message,1,0}

depending on sleep or non-sleep node.

I think that every SEARCHGW packets should be answered. Why?
Sometimes a node can be restarted manually or maybe it suffers an operation/hardware error and it's restared accidentally. When they turn on again and, in the case nodes haven't set gateway address on firmware or software config, they should ask for gateway id before they can connect to GW again.

Now, I can't reconnect wireless nodes if they are restared due to SEARCHGW is not reply unless I force disconnection on xbee-udp forwarder.

Thank and regards.

undefined macro 'SN_RC_MQTT_FAILURE'

emq_sn_gateway.erl:592

Feature request: Wildcards

Hi, this is a feature request. Could you implement support for wildcards (single level + and multilever #)? :)