How to use aws_fota program in nRF9160?

[Yusuke]

I'm trying to use aws_fota, but it doesn't work. Any help?

I was able to set a job on AWS IoT, but the download job doesn't start. The job status is always "in progress". I logged out and logged in and got the same result.

***** Booting Zephyr OS v1.14.99-ncs2 *****
The MQTT AWS Jobs FOTA Sample
LTE Link Connecting ...
LTE Link Connected!
IPv4 Address 0x4980a023
client_id: nrf-352656100218455
[mqtt_evt_handler:131] MQTT client connected!
[mqtt_evt_handler:196] SUBACK packet id: 2112
[mqtt_evt_handler:186] PUBACK packet id: 62996

I use the same region in AWS IoT and S3

I've already checked this thread.
https://devzone.nordicsemi.com/f/nordic-q-a/52039/aws-fota-sample/210098#210098

[Øyvind]

Hello, 

Good to see that the connection is working. 

Can you please provide your AWS Job file as well? And where is the .bin file located?

Thanks!

Kind regards,
Øyvind

[Yusuke]

Thank you for your help!

I'm using Oregon region.

This is a job file

{
  "operation": "app_fw_update",
  "fwversion": "v1.0.2",
  "size": 64300,
  "location": {
    "protocol": "https:",
    "host": "******.s3-us-west-2.amazonaws.com",
    "path": "/20190929_test_update.bin"
   }
}

.bin file is located in S3 in Oregon region.

[Øyvind]

I'm sorry, the AWS_FOTA is intended to be used against nRF Cloud. The documentation is lacking this information but has been reported. Have a look at the HTML Application Update sample documentation, which also uses the Download Client to download the image.

As stated in the Limitations section of the AWS_FOTA library
"Currently, the library only uses HTTP for downloading the firmware. It is, however, possible to have it work with HTTPS - see Download client. These changes need to be applied to FOTA Download to enable downloading firmware through HTTPS."

[Yusuke]

Thank you for reporting. I'm confused.

Do both of aws_fota and http_application_update require you to use nRF Could?

And I hope Nordic engineers will make a sample fota program using AWS without nRF Cloud. 

[Øyvind]

Hello, 

To clear the confusion I have forwarded this question to our NCS team. I will get back to you as soon as possible. 

Kind regards,
Øyvind

[Yusuke]

Alright. I'll be waiting for your reply

[sigvartmh]

Hi, it's possible to use the AWS FOTA and HTTP application update sample with any server that can respond with the content-range header. To be more precise, it needs to support this formatting of the content-range.

Content-Range: <unit> <range-start>-<range-end>/<size>

It is the Download Client library that sets this limitation.  

AWS S3 buckets do respond with this, but the file has to be accessible for the device. To find out if it is, I recommend turning on CONFIG_LOG=y and CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y to see what the header response is.

I guess that you get either a 403 forbidden or 301 permanent redirects response in the header.

If you want to test downloading from an S3 bucket, it is easiest to make the files in the bucket public. This can be done by going to the S3 Console, then go bucket>permissions>block public access and deselect the two options which regard blocking public access through policy. 

Then you can attach the following policy to your bucket by going to bucket>permissions>bucket policy

{    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<bucket name>/*"
        }
    ]
}

Then press save. It should be noted that this makes you file publicly available to anyone who has the link.

After you have done this the format of your job file should be 

{
  "operation": "app_fw_update",
  "fwversion": "v1.0.2",
  "size": 64300,
  "location": {
    "protocol": "http:",
    "host": "******.s3-us-west-2.amazonaws.com",
    "path": "20190929_test_update.bin"
   }
}

The Download client library now appends the / between host and path. It should also be noted that this will use HTTP to download the file(this is possible with the S3 bucket) in a standard configuration, so no change is needed.

[Yusuke]

Hi, sigvartmh

Thank you for your advice. Unfortunately, I can't solve the issue yet.

I got the same result. I added to these two lines to prj.conf and check the log on LTE Link Monitor.

When I added CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y to prj.conf, an error was caused so I fixed Kconfig.

<prj.conf>

CONFIG_LOG=y
CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y

<Kconfig>

config DOWNLOAD_CLIENT_LOG_LEVEL_DBG
	bool "debug level"

<LTE Link monitor>

***** Booting Zephyr OS v1.14.99-ncs2 *****
The MQTT AWS Jobs FOTA Sample
LTE Link Connecting ...
LTE Link Connected!
IPv4 Address 0x1f39d522
client_id: nrf-352656100218455
[mqtt_evt_handler:131] MQTT client connected!
[mqtt_evt_handler:196] SUBACK packet id: 2112
[mqtt_evt_handler:186] PUBACK packet id: 24675

<AWS S3 access setting>

In addition, now I can't update bucket>permissions>bucket policy.

Any help?

[sigvartmh]

Is this the full LTE Link Monitor output? If so, it seems that your device did not receive a job from AWS. I recommend to cancel and delete any old jobs which may be in AWS. Before you try to create a new job, also maybe wait until the device is connected before you create it.

With regards to the S3 Bucket, I see that the Oregon configuration is a bit different and the one I used. This is how you should have configured it.

Then you should be able to update the bucket policy with the policy I posted as it will allow you to set public access to the file through a policy.

Also, I forgot to tell you to set CONFIG_DOWNLOAD_CLIENT_LOG_HEADER=y which will log out the HTTP headers so that you can ensure that you don't get a 403 or 301 response in the HTTP header.

[Yusuke]

Let me confirm one thing.

A Job must be created after MQTT connection, right? If it is created BEFORE connection, isn't it be downloaded?

[sigvartmh]

Yes,/no is my answer. If you are on the tagged version, A Job must be created after the MQTT connection. If you are on the master branch, this should no longer be the case as the device should fetch any queued jobs for the device and will take the first job queued for the device.

It could be that AWS has changed their policy configurations from when the documentation was written and the current thing policy is not seen as valid.  Could you try to attach the following policy to the certificates your device uses? See if it is then able to accept jobs.

[Yusuke]

My ncs version is v1.0.1, is this tagged version?