9

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.

Firstly, I open a network socket with AT+NETOPEN, then open a TCP connection with AT+CIPOPEN=0,"TCP","ip address",port. 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.

Improve this question
7
  • 2
    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 2, 2018 at 5: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 2, 2018 at 6:13
  • 2
    What language and MQTT libraries are you using for your client? Please update your posted question with this information.
    – Richard Chambers
    Jan 2, 2018 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 2, 2018 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 2, 2018 at 19:46

2 Answers 2

Reset to default
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.

Improve this answer
4
  • 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 2, 2018 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 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 2, 2018 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 3, 2018 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, 2020 at 23:05
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.