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

nrf9160 serial interface with HTTPS support for large POST

I'm evaluating feasibility and developing a Proof-of-Concept for a client using the NRF9160 + NRF52840.   This is a second generation product where the client wants to evaluate the possibility of integrating the connectivity solution of the NRF9160 with a code-base that was developed several years ago on NRF52832.  The existing implementation communicates over BLE to another device which integrates a LTE/Cat-M1 modem.  That modem included support for HTTPS and a filesystem for storing the large data objects.

For the new system, the interface between the NRF52840 and the NRF9160 will be UART / serial.  

The requirements include: 

* securely upload data to a cloud service, existing interface sends large data blocks up to hundreds of kilobytes via HTTPS

* download data objects such as DFU images from an HTTPS service.. these might be several hundred kilobytes as well

* ability to update all components in the system with images sourced from the cloud  (e.g. must be able to update the non-secure application in nrf9160 and the application running in nrf52840)

* all updates must be able to complete atomically without user intervention... in other words all images must be downloaded, authenticated/verified and only then installed.

Currently in the design there is a flash memory connected to the nrf52840, but not the nrf9160.

In the nRFConnect SDK 1.5.1, I see that there are some relevant examples

* https_client - installs a certificate and performs a small https query

* at_client - pass through of AT commands from serial to internal modem.

It seems from https_client example, the management of data sent to the http server is primarily handled by the end-user application code.  If I understand it correctly, we would create the HTTP header and body in application code and then send it to a socket connected to the port. 

I have some initial concerns, that I would  like some help to get oriented:

1) What would be required from AT_Client example interface to initiate and send an HTTP POST request ?   It appears using AT client interface that all of the socket code, tls, keys etc would need to be included into the nrf52840 since they seem to be built on top of the modem AT commands.

2) Is there any sort of timeout on socket used in https request?  For example if the body is several hundred kilobytes and the transfer rate is limited... will the socket close?

3) Is there an https_client library code provided or recommended third party library ? 

3a) I noticed in zephyr\inlcude\net\http_client.h which was not used in https_client example.  Is it possible to Zephyr's http_client code with the TLS secured socket demonstrated in https_client?

4) Which solution would require less work:

    option a) using existing AT_client in nrf9160  (seems hard since zephyr socket / tls code would need to be shifted into non-zephyr code base)

    option b) extending AT_client protocol to provide an command for controlling http client    (is it possible to extend AT_client protocol?)

    option c) creating a custom serial protocol into code based on https client?  (must create robust serial protocol for https)

5) Is there another approach I should consider besides AT_client vs https_client?

6) Is there a protocol or example for updating nrf9160 application via serial interface?

7) Is it recommended to attach a flash chip to nrf9160 for DFU?  For example can the socket rate limit to match the data rate of the serial/uart connection?

8) How can I determine the flash and ram size of the http client example?  ( I want to know how much space is left for buffering and for additional feature development)

Parents Reply Children
  • No, my progress has been slow.  (I have a few too many projects at the same time!) 

    I am considering the Content-Range approach for downloads.

    For uploads, in my project, we are able to limit the data sent to under the limit... although this is far from ideal since for our existing servers each upload has a large overhead.

    Also, I think it might be possible to modify the http_client to use native tls sockets.  Although it doesn't support it in the SDK as implemented by Nordic, it would seem possible to modify the http_client in the SLM source.

    BUT..  the TLS fragmentation negotiation would probably be an even better solution.  Does the modem firmware support the TLS fragmentation negotiation?  

    From reading the IETF RFC6066.. https://datatracker.ietf.org/doc/html/rfc6066#page-8

    It seems the client must send the acceptable maximum fragments lengths in the extended client hello.  I wonder, does the modem firmware TLS stack send this extension?

Related