• State Verified Answer
  • Replies 5 replies
  • Subscribers 68 subscribers
  • Views 161 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 335276
Options

Managing TCP Retransmission Timeout

vytautas.virvicius

During our evaluation of MQTT, we observed that if we send data every five minutes, the server stops receiving it. We currently believe this is related to CG-NAT, which drops the tunnel due to inactivity, preventing the packet from being routed. This leads to the module retransmitting the TCP packet 10 times with varying delays before determining that the TCP connection is dead. The entire process takes approximately 18 minutes.

Is there a way to control the frequency of retransmissions or the total time before considering the TCP connection dead?

Parents
  • +1

    Hi,

    The retransmission count feature is built on top of the basic TCP/IP socket and is not inherently part of the core TCP stack. Due to the limited resources on the modem running on the nRF9151, this feature is not supported.

    As I mentioned, I would recommend referring to the Zephyr TCP stack. Zephyr's implementation provides enhanced capabilities, including retransmission counting. If resource constraints are a concern, you might consider porting only the specific parts of the code relevant to your needs to minimize size increases

    Best regards,

    Charlie

Reply
  • +1

    Hi,

    The retransmission count feature is built on top of the basic TCP/IP socket and is not inherently part of the core TCP stack. Due to the limited resources on the modem running on the nRF9151, this feature is not supported.

    As I mentioned, I would recommend referring to the Zephyr TCP stack. Zephyr's implementation provides enhanced capabilities, including retransmission counting. If resource constraints are a concern, you might consider porting only the specific parts of the code relevant to your needs to minimize size increases

    Best regards,

    Charlie

Children
No Data
Related