This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF9160 issue in receiving TLS packets larger than 2048 bytes

When nRF9160 receives a TLS packet > 2048 bytes the socket closes unexpectedly. This problem has been documented in other tickets here and I believe noted in the nrf_modem library.

- Is this fixable in a future firmwae/library release or is it an architecture limitation of the modem?

- Are thre plans to fix this?

With the 2048 byte limit using AWS Shadow documents (and a few other AWS features) is practically impossible because they can easily exceed 2K with the timestamp metadata that AWS adds to each key. We've also run into this issue when downloading over HTTP TLS.

Parents
  • Hi Arvin,

    The buffer in the modem is not changeable so this is a locked restriction in the modem.  But if you consider using the app-core you can look at Zephyr-TLS witch uses mbedtls. 

    Are thre plans to fix this?

    To get more information about roadmap/future updates contact your local RSM. 

    Regards,
    Jonathan

  • Hello Jonathan,

    What is the app-core and how do I reconfigure my application (asset_tracker_v2) to experiment with it?

    Also, I spent the last month or two trying to debug a packet size issue: I had modified asset_tracker_v2 to subscribe to a topic with a wildcard, and doing so caused me to subscribe to the shadow document, which is almost 4000 bytes. The result was that I received a disconnect message like follows:

    [00:01:05.928,405] <dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_DISCONNECT: result = -128
    [00:01:05.936,645] <dbg> aws_iot_integration.aws_iot_event_handler: AWS_IOT_EVT_DISCONNECTED
    [00:01:05.945,831] <dbg> aws_iot.aws_iot_cloud_poll: The cloud socket is already closed.

    There was absolutely no way I could know what the problem is without either setting up the Trace Collector or another alternative. Basically, AWS believed that I had closed the connection, and the nRF9160 messages above suggested that AWS closed the connection. "The other guy did it!" Now, my understanding is that Trace Collector is not something that helps me unless I get you folks involved. I wanted to troubleshoot on my own.

    The way I debugged: I found an ESP32 around the house, and I set it up to use ZephyrOS. I used their mqtt_publisher example and enhanced it with some help from your aws_iot.c. So I set it up to both publish and subscribe. As the asset_tracker_v2 was seeing the MQTT_EVT_DISCONNECT right after publishing a message, I used DBG to see the contents of the message and the topic it was published to. So I did that in my ESP32 program. Note that the ESP32 uses mbedtls. I very quickly found that my buffer was too small. I enlarged it and the problem disappeared. Of course, enlarging the buffers on the nRF9160 did not help because of the limited size hardware buffer.

    Why isn't there a way to have the nRF9160 modem return a message to me indicating the buffer size problem?

    I have given you a few questions; I hope you can answer each one. Thank you.

    Regards,

    Burt

  • Hi Jonathan,

    I hope I clicked the correct reply button--the interface sometimes confuses me...just for curiosity: I thought you were suggesting to Arvin that one could experiment with running the IP/TCP/TLS stack in the app-core. I don't think I'd want to do that often, but if it is possible to run the stack in the app-core, then could you point me to a sample that demonstrates this? Anyway, more interesting will be what the devs say about getting an indication from the modem that internal buffer size has been exceeded.  Thank you very much. I know in practice this "shouldn't happen," but every debug trick is nice to be aware of.

    Burt

  • Hi Burt,

    Burt said:
    Anyway, more interesting will be what the devs say about getting an indication from the modem that internal buffer size has been exceeded.

    There are no plans to change this part of the interface. Exactly how the modem handles the situation is closed source so nothing you can use or modify. The socket is closed due to a invalid length error from the network.  


    The way around this issue or to best debug is to provide a modem trace, and work from there. But for a buffer full error the issue is best handled on the network/cloud side, so to make sure that the Cloud don't send to much data.
    Regards,
    Jonathan

  • Thank you, Jonathan, but I need more help: I don't know where Socket Closed and Error invalid length are defined. I have tried to google these, and also search on some linux systems under /usr/include, and I searched the SDK repositories. These must be private terms. Please show me where they are defined, and perhaps show me a sample implementation that would print an error message showing the length issue. I am not looking for big changes; I just want to know how to use the existing interface to give detailed information.

    Burt

  • The way to handle this issue is with proper system design and there is no way to make a response in NCS for the buffer size issue to be acted upon. 

    Edit: i have to retract some info form previous statement/reply, both for clarification and to limit the specific info shared. Sorry for the inconvenience. 
    Regards,
    Jonathan

  • No problem with the retraction, Jonathan, and thank you for correcting my overly optimistic idea that I could see the over-sized packet issue directly. Of course, a good design won't be using huge packets in the first place, but it was tempting to take a deep dive into how to debug a bad design.

    Regards,

    Burt

Reply Children
No Data
Related