• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 90 subscribers
  • Views 1166 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 283986
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AWS IoT Send Function Error -128 and maintaining connection

jake11212

I'm working on the 9160 SoC using nRF Connect SDK 1.8.0 to send MQTT messages to an AWS endpoint.  The messages correctly are able to send and the device works for 5-10 minutes but then fails giving error -128.  I looked this up to be ENOTCONN which makes me think that something is causing the connection to time out, but I couldn't find anything in the AWS documentation or SDK 1.8.0 documentation that would cause this.  Is there any reason that would cause this disconnection, and is there any example of the protocol for staying connected?  The goal of my program is to be constantly ready to send MQTT messages when contacted over BLE so I want to always be connected if possible.

Thanks!

Parents
  • +1

    Hi,

     

    It sounds like your connection times out. Each network is configured (and routed) differently, so the NAT timeout for your network path sounds to be lower than 5-10 minutes.

    Could you check what your "CONFIG_MQTT_KEEPALIVE" is set to, and try to lower this value? 

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    So if I'm understanding correctly the network for the NAT time is timing out after 5-10 minutes but it's only set to receive the KEEPALIVE packets every 20 mins since CONFIG_MQTT_KEEPALIVE is currently set at 1200.  So since it didn't receive the packets in time it's disconnecting.  Is there a way to check the NAT timeout for the network path to verify that my keepalive timer is within the range of the NAT timeout?  Or do I need to test this manually?  

  • 0 in reply to jake11212

    Hi,

     

    jake11212 said:
    So since it didn't receive the packet in time it's disconnecting.  Is there a way to check the NAT timeout for the network path to verify that my keepout timer is within the range of the NAT timeout?  Or do I need to test this manually?  

    You can contact your network operator and ask, or you can reduce CONFIG_MQTT_KEEPALIVE to a point where it starts to work (divide it by 2, test, if not working, divide by 2 again).

    Do note that this also depends on the keep-alive of your mqtt broker as well as your "network chain".

     

    Kind regards,

    Håkon

Reply
  • 0 in reply to jake11212

    Hi,

     

    jake11212 said:
    So since it didn't receive the packet in time it's disconnecting.  Is there a way to check the NAT timeout for the network path to verify that my keepout timer is within the range of the NAT timeout?  Or do I need to test this manually?  

    You can contact your network operator and ask, or you can reduce CONFIG_MQTT_KEEPALIVE to a point where it starts to work (divide it by 2, test, if not working, divide by 2 again).

    Do note that this also depends on the keep-alive of your mqtt broker as well as your "network chain".

     

    Kind regards,

    Håkon

Children
No Data
Related
Terms of service