10

I have been working on an MQTT protocol using the SIM5320. I am familiar with the AT command documentation, and have a working implementation with an Arduino.

  1. I open a network socket with AT+NETOPEN
  2. Then I open a TCP connection with AT+CIPOPEN=0,"TCP","ip address",port.
  3. I then transmit data for the MQTT protocol using AT+CIPSEND, which executes successfully.

If I send data to the SIM module through MQTT, it is also received and the message is detected.

With MQTT, there is a Keep-Alive interval which specifies how long the server will keep a connection open between communication, basically how long the client can idle before being forcibly disconnected from the server. However, I have set this value to the maximum of 18 hours, which is far longer than the ~15 minute disconnections.

My issue arises after ~15 minutes, when I try sending a command to the server, and no response is given. The SIM has not issued a "+IPCLOSE: 0,4", which usually occurs when the server forcibly disconnects the client, or any other sort of indicator.

Additionally, I am still able to send data and it appears that the CIP connection is still open, as indicated by AT+CIPOPEN?. When I try and close the connection with AT+CIPCLOSE=0, I receive +CIPCLOSE: 0,4 and "ERROR". There is no mention of what +CIPCLOSE: 0,4 means in the documentation, however it does not seem to close the connection, as it cannot be opened or used.

I would really love to know what is happening in this 15 minutes, between establishing a connection and sending data, to attempting to send data again. There is no alert or any indication of anything going wrong, so I am seriously confused.

I initially asked this question on Electrical Engineering stack exchange, but was advised to ask it here as well.

I've attached the code I wrote here for anyone who would like to take a look, and there aren't any libraries you need to run it.

Rohit Gupta
  • 285
  • 1
  • 2
  • 12
Boris Deletic
  • 203
  • 1
  • 6
  • 3
    Looking at MQTT Keep Alive Interval Explained it would appear that the most likely cause is the transport connection is being dropped at some point within the communications stack. Sending data should keep the MQTT communication up and the broker should be sending pings back down if it is not sending anything else. So could the modem be going into sleep if there is no activity? One question would be whether you could send a ping message every 10 minutes when there is no other traffic and how that happens. – Richard Chambers Jan 02 '18 at 05:08
  • 1
    If I send a ping request before the connection drops, then the connection stays active. However sending ping requests every 10 minutes is more problematic as opposed to sending them every 18 hours. If possible, I'd like to only send requests every hour or so. – Boris Deletic Jan 02 '18 at 06:13
  • 2
    What language and MQTT libraries are you using for your client? Please update your posted question with this information. – Richard Chambers Jan 02 '18 at 14:50
  • 1
    The OP is using a 3G module that sends TCP/IP packets based on AT commands sent to the module via a UART link. There is no Linux involved here at all. The OP is basically writing his own MQTT client. – hardillb Jan 02 '18 at 15:31
  • 1
    @hardillb ok that clarifies things a bit. So then if the OP is writing his own MQTT client from scratch then it would seem that the work should follow the MQTT specification which includes the necessary MQTT Keep Alive pings. – Richard Chambers Jan 02 '18 at 19:46
  • It Could be possible to send a periodical wakeup "AT", to keep the SIM5320 awake. It will be useful if you post your .ino code with libraries you are using, to see the AT-commands sequence. – Carlos Moreno Salazar Jan 02 '18 at 23:22
  • I have attached a link with my code. – Boris Deletic Jan 04 '18 at 07:43

2 Answers2

7

Default TCP/IP timeout is 15mins, you must send something inside this interval to keep the underlying TCP connection alive, even if it's just a sync/ack pair.

The MQTT keepalive is to do with when to trigger the Last Will and Testement messages.

hardillb
  • 12,553
  • 1
  • 20
  • 34
  • 1
    The MQTT keepalive is to do with when to decide to close what may be a dead connection or a live connection to a dead agent (client or broker). This in turn triggers the Last Will and Testament. Keepalive is not to trigger Last Will and Testament but rather to decide if a connection is dead, to close it, and as part of closing the connection to trigger Last Will and Testament. – Richard Chambers Jan 02 '18 at 14:50
  • 1
    Could you provide more details about the TCP/IP timeout you are referring to? I assume you are talking about the unacknowledged transmission timeout which would not seem to apply to the posted question but am not sure. And according to http://man7.org/linux/man-pages/man7/tcp.7.html there is tcp_keepalive_time() with a default value of 7200 seconds after which keep alives are sent if the SO_KEEPALIVE socket option is set Otherwise the connection is terminated. – Richard Chambers Jan 02 '18 at 15:18
  • 1
    This would appear to be the cause of the issue, could you please add a citation and suggest a possible method to increase this interval for the SIM5320? – Boris Deletic Jan 03 '18 at 21:19
  • We're seeing something very similar with our MQTT setup - TCP seems to disconnect but the MQTT client/broker are unaware. When we publish after ~30mins of inactivity, a PUBACK is not received from the broker, but as far as the broker is concerned a disconnect has not occurred either. – Steve Magness Mar 31 '20 at 23:05
2

Try enabling TCP keep alive with a shorter period than 15 minutes, you should be able to enable TCP keep alive from your server and/or from your device (SIM5320), enabling either one should solve your problem.

In the SIM5320 you can use AT+CTCPKA to enable TCP keep alive.

In your server, enable socket.SO_KEEPALIVE

This is transparent to the TCP user (you), so it should not interfere with your application, as opposed to the accepted answer.

Tomás Arturo Herrera Castro
  • 21
  • 1