nRF9160 issue in receiving TLS packets larger than 2048 bytes

[af2377]

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.

[JONATHAN LL]

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

[Burt]

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

[JONATHAN LL]

Hi,

Burt said:

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

app-core is the term used for the application core, everting of our samples and app in the SDK-nrf runs on the app-core. The other "core" is the modem.  


The IP stack is in the modem and the problem seems to be that the TLS buffer is full so the TCP connection is terminated by the modem. 
So the solution is to not exceed 2K. 

The way this is done in the Asset Tracker v2 is to make a IOT-rule in AWS that selects the wanted/necessary info from the shadow and publishes that on a different topic. 

Burt said:

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

 not sure if i am able to gat good answer here but i will check with the devs

Regards,
Jonathan

[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

[JONATHAN LL]

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