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.

[Burt]

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

[JONATHAN LL]

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

[Burt]

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