Running out of RAM during OTA update about mongoose-os

[rojer]

E:M 16421 (2054 blocks)

this is a known issue with TLS - records can be up to 16K in size and it entirely depends on the server.
if it decides to send us 16K of data, we hav eno choice but to deal with it.
well, the way to deal with it is record fragmentation but as of today it is not supported by mbedtls.
the only possible workaround is to manipulate server side to send data in smaller chunks.
that is, to flush data more often.

[fabio-mantelli]

Thanks for the answer. I have noticed in the debug that in the HTTP request header, there is the "Range" field, but only with the range start, but not the end. Perhaps an alteration could be made and a config parameter could be added where we can set the maximum response chunk size and the library automatically sets the range start and end in the HTTP header. Since there is a "extra_http_headers" config in the ota-http-client library, I imagine such functionality is possible. I think this would solve the issue with servers that can reply adequately to such requests.

We are using AWS cloud platform, and we are having trouble finding a way to manipulate the S3 or CloudFront, or any other service to send smaller chunks.

The work around we found was to whenever we get an OTA update request from shadow, we disable some features on the mongoose os and reboot the device with just enough functionalities to perform OTA through a local RPC call. This way we free some RAM when we wish to perform OTA updates. After that we enable the features again in case the update fails and reboot the device.

I would like to recommend that this issue is mentioned somewhere in documentation.