MQTTSN Example: Client unable to reconnect to Broker after timeout

[Brian (Geek)]

Hello,

I am currently using mqttsn publisher exams with keep allive time of 30 seconds, so according to MQTT standard if period of inactivity will be 45 second and the client is unable to recieve ping response or broker doesn't recieve ping request from client in fixed time it will break the connection.

I would like to know how could I reconnect client to the broker once the broker timesout the client connection. Currently I am checking the state of client using isConnected api but it indeed take 3-4 minutes to restablish a connection. 

I would like to re-establish a connection as soon as the mqtt-sn client get's time out. I can't wait for 2-3 minutes to connect to broker. Also currently I have to wait for the next publish to check whether my client is connected to broker or not.

For Example: if I take a python MQTT client with keep alive time of 60 second and turn off and turn on the mosquito broker , the python client immediately connects within few seconds. I want some solution like that for mqtt-sn client. 

Please provide some tried and tested code or help for the same.  

[Brian (Geek)]

Hello Sigurd,

I will wait for your response. 

Can you tell me how can I implement your suggestion. If a event timeout occur it's reason could be anything I guess. And  also for a client to get timedout, it will wait for 1.5 times the keep alive time before disconnecting if no ping response is received. 

[Sigurd Hellesvik]

Hi

Sigurd Hellesvik said:

In the meantime, you could try to manually disconnect and connect the client when you get a timeout event.

Yea, this will be inefficient. So lets try to find a way to find if there is another way first.

First:

For Example: if I take a python MQTT client with keep alive time of 60 second and turn off and turn on the mosquito broker , the python client immediately connects within few seconds. I want some solution like that for mqtt-sn client. 

You test a MQTT client versus a MQTT-SN client. Could you try to find a python MQTT-SN server to test with?
This is to test if the issue is with the MQTT-SN protocol.

Secondly:

Do you receive a disconnect callback in the code at the nRF client when you disconnect the broker?

Third:

A sniffer log would be useful. Could you set up the nRF Sniffer for 802.15.4, and sniff to see if a disconnect event is sent when you disconnect the broker?

Regards,
Sigurd Hellesvik

[Brian (Geek)]

Sigurd Hellesvik said:

Secondly:

Do you receive a disconnect callback in the code at the nRF client when you disconnect the broker?

Third:

Hello, i have tried debugging using Segger Studio with both mqttsn publisher/sleepy publisher example and adding a break point at below mqttsn_event handler case.Program never stops here at the below code, so the following event never get generated.

   

    case MQTTSN_EVENT_DISCONNECT_PERMIT:
            NRF_LOG_INFO("MQTT-SN event: Client disconnected.\r\n");
            disconnected_callback();
            device_connection_status = DEVICE_DISCONNECTED;
            break;

the disconnect_callback function never gets called. So second answer is NO.

Sigurd Hellesvik said:

Third:

A sniffer log would be useful. Could you set up the nRF Sniffer for 802.15.4, and sniff to see if a disconnect event is sent when you disconnect the broker?

Third:
A sniffer log would be useful. Could you set up the nRF Sniffer for 802.15.4, and >sniff to see if a disconnect event is sent when you disconnect the broker?

I don't see any disconnect packet sent, you can also verify the sniffed packets. I have attached two sniffer package: 1) After Broker has been shutdown 2) Full Communication

afterbrokerdisconnected.pcapng

FullPacketCapture.pcapng

Regarding first i would try to find out by R&D.

Sigurd Hellesvik said:

You test a MQTT client versus a MQTT-SN client. Could you try to find a python MQTT-SN server to test with?
This is to test if the issue is with the MQTT-SN protocol.

[Brian (Geek)]

Hello Sigurd,

Quick Update: I have updated the mqtt-sn gateway on Nordic border router image to the one used in the docker image link which you have provided. I tried updating mqtt-sn gateway to the master branch but the configuration have changed now. So I have stick with the mqtt-sn gateway commit used in Docker Image. So my MQTT-SN gateway is almost up-to-date.

As you asked me about whether I am getting MQTTSN disconnect event. Answer is yes, in mqqtsn_event handler i am getting MQTTSN DISCONNECT event. Also in the mqtt-sn logs, when I shut down the broker I can see disconnect packet sent to client. So that aspect is working fine. But in Mqtt-sn disconnect event, than I have to try to connect to gateway manually. Can that be automated like somewhere in background similar to normal python MQTT client ? 

Also I am facing a new issue now. With the updated mqtt-sn gateway on border router, whenever I shut-down the broker it gives me a assertion error one by one in mqttsn_client.c file state changed function. In that switch case of CLIENT CONNECTEd, disconnected and establishing connection give me assertion error whenever I shut down the broker. Why is it so ? 

[Sigurd Hellesvik]

Hi Brian

Brian (Geek) said:

As you asked me about whether I am getting MQTTSN disconnect event. Answer is yes, in mqqtsn_event handler i am getting MQTTSN DISCONNECT event. Also in the mqtt-sn logs, when I shut down the broker I can see disconnect packet sent to client. So that aspect is working fine. But in Mqtt-sn disconnect event, than I have to try to connect to gateway manually. Can that be automated like somewhere in background similar to normal python MQTT client ? 

I do not know of any way to make this reconnect automatically. Since that MQTTSN implementation does not seem to do this automatically, you will have to fix this manually in the mqttsn_event_handler in your application.

Brian (Geek) said:

In that switch case of CLIENT CONNECTEd, disconnected and establishing connection give me assertion error whenever I shut down the broker. Why is it so ? 

This crashes due to the handler not being able to handle a fsm_event. The fsm_event can have the following values:

/**@brief MQTT-SN events that cause MQTT-SN client's state to change. */
typedef enum client_state_fsm_event_t
{
    SENT_SEARCHGW,                  /**< SEARCH GATEWAY message was sent. */
    SENT_CONNECT,                   /**< CONNECT message was sent. */
    SENT_PINGREQ,                   /**< PINGREQ message was sent. */
    SENT_SLEEP_REQUEST,             /**< DISCONNECT message with sleep duration was sent. */
    SENT_DISCONNECT_REQUEST,        /**< DISCONNECT message without sleep duration was sent. */

    RECEIVED_CONNACK,               /**< CONNACK message was received. */
    RECEIVED_SLEEP_PERMISSION,      /**< Response to a DISCONNECT message with sleep duration was received. */
    RECEIVED_DISCONNECT_PERMISSION, /**< Response to a DISCONNECT message without sleep duration was received. */
    RECEIVED_DISCONNECT,            /**< DISCONNECT message sent not as a response (disconnected by the gateway). */
    RECEIVED_PINGRESP,              /**< PINGRESP message was received. */

    TIMEOUT_SEARCHGW,               /**< Timeout occurred when waiting for GWINFO message. */
    TIMEOUT_CONNECT,                /**< CONNECT message retransmission limit has been reached. */
    TIMEOUT_PINGREQ                 /**< PINGREQ message retransmission limit has been reached. */
} client_state_fsm_event_t;

If you are able to find the value of the fsm_event int the MQTT_CLIENT_CONNECTED switch case, this could give an indication to why it will crash on broker disconnect.

Regards,
Sigurd Hellesvik