blob: 4a1e65dc2f44679a518bf11628ea292a0b4dece0 [file] [log] [blame] [view]
# ota-provider-app
This is a reference application that implements an example of an OTA Provider
Cluster Server.
## Build
Suggest doing the following:
```
scripts/examples/gn_build_example.sh examples/ota-provider-app/linux out/debug chip_config_network_layer_ble=false
```
## Usage
| Command Line Options | Description |
| ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| -a, --applyUpdateAction \<proceed \| awaitNextAction \| discontinue\> | Value for the Action field in the first ApplyUpdateResponse.<br>For all subsequent responses, the value of proceed will be used. |
| -c, --userConsentNeeded | If supplied, value of the UserConsentNeeded field in the QueryImageResponse is set to true. This is only applicable if value of the RequestorCanConsent field in QueryImage Command is true.<br>Otherwise, value of the UserConsentNeeded field is false. |
| -f, --filepath \<file path\> | Path to a file containing an OTA image |
| -i, --imageUri \<uri\> | Value for the ImageURI field in the QueryImageResponse. If none is supplied, a valid URI is generated. |
| -o, --otaImageList \<file path\> | Path to a file containing a list of OTA images |
| -p, --delayedApplyActionTimeSec \<time in seconds\> | Value for the DelayedActionTime field in the first ApplyUpdateResponse.<br>For all subsequent responses, the value of zero will be used. |
| -q, --queryImageStatus \<updateAvailable \| busy \| updateNotAvailable\> | Value for the Status field in the first QueryImageResponse.<br>For all subsequent responses, the value of updateAvailable will be used. |
| -t, --delayedQueryActionTimeSec <time> | Value for the DelayedActionTime field in the first QueryImageResponse.<br>For all subsequent responses, the value of zero will be used. |
| -u, --userConsentState \<granted \| denied \| deferred\> | The user consent state for the first QueryImageResponse. For all subsequent responses, the value of granted will be used.<br>Note that --queryImageStatus overrides this option.<li> granted: Status field in the first QueryImageResponse is set to updateAvailable <li> denied: Status field in the first QueryImageResponse is set to updateNotAvailable <li> deferred: Status field in the first QueryImageResponse is set to busy |
| -x, --ignoreQueryImage \<ignore count\> | The number of times to ignore the QueryImage Command and not send a response |
| -y, --ignoreApplyUpdate \<ignore count\> | The number of times to ignore the ApplyUpdate Request and not send a response |
| -P, --pollInterval <milliseconds> | Poll interval for the BDX transfer. |
**Using `--filepath` and `--otaImageList`**
- The two options cannot be supplied together
- At least one option must be supplied
- If `--filepath` is supplied, the application will automatically serve that
file to the OTA Requestor
- If `--otaImageList` is supplied, the application will parse the JSON file
and extract all required data. The most recent/valid software version will
be selected and the corresponding OTA file will be sent to the OTA Requestor
- The SoftwareVersion and SoftwareVersionString sent in the QueryImageResponse
is derived from the OTA image header. Please note that if the version in the
`--otaImageList` JSON file does not match that in the image header, the
application will terminate.
An example of the `--otaImageList` file contents:
```
{ "foo": 1, // ignored by parser
"deviceSoftwareVersionModel":
[
{ "vendorId": 1, "productId": 1, "softwareVersion": 10, "softwareVersionString": "1.0.0", "cDVersionNumber": 18, "softwareVersionValid": true, "minApplicableSoftwareVersion": 0, "maxApplicableSoftwareVersion": 100, "otaURL": "/tmp/ota_v10.bin" },
{ "vendorId": 1, "productId": 1, "softwareVersion": 20, "softwareVersionString": "1.0.1", "cDVersionNumber": 18, "softwareVersionValid": false, "minApplicableSoftwareVersion": 0, "maxApplicableSoftwareVersion": 100, "otaURL": "/tmp/ota_v20.bin" },
{ "vendorId": 1, "productId": 1, "softwareVersion": 30, "softwareVersionString": "1.0.2", "cDVersionNumber": 18, "softwareVersionValid": true, "minApplicableSoftwareVersion": 0, "maxApplicableSoftwareVersion": 100, "otaURL": "/tmp/ota_v30.bin" },
{ "vendorId": 1, "productId": 1, "softwareVersion": 40, "softwareVersionString": "1.1.0", "cDVersionNumber": 18, "softwareVersionValid": true, "minApplicableSoftwareVersion": 0, "maxApplicableSoftwareVersion": 100, "otaURL": "/tmp/ota_v40.bin" },
{ "vendorId": 1, "productId": 1, "softwareVersion": 50, "softwareVersionString": "1.1.1", "cDVersionNumber": 18, "softwareVersionValid": false, "minApplicableSoftwareVersion": 0, "maxApplicableSoftwareVersion": 100, "otaURL": "/tmp/ota_v50.bin" }
]
}
```
## Software Image Header
All Matter software images must contain a header as defined in section 11.21.1
of the specification. The
[ota_image_tool](https://github.com/project-chip/connectedhomeip/blob/master/src/app/ota_image_tool.py)
is available for generating the required header on a software image.
All images supplied to the OTA Provider application (via `--filepath` or
`--otaImageList`) must contain the software image header. The OTA Provider
application will use the software version specified in the header to set the
`SoftwareVersion` field of the QueryImageResponse. For instance, if the image
supplied represents an image with software version 2, the tool can be used as
follows:
```
src/app/ota_image_tool.py create -v 0xDEAD -p 0xBEEF -vn 2 -vs "2.0" -da sha256 firmware.bin firmware.ota
```
Please see this
[section](https://github.com/project-chip/connectedhomeip/tree/master/examples/ota-requestor-app/linux#generate-images)
for information on building an OTA Requestor application with a specific
software version.
## Access Control Requirements
Commissioner or Administrator SHOULD install necessary ACL entries at
commissioning time or later to enable processing of QueryImage commands from OTA
Requestors on their fabric, otherwise that OTA Provider will not be usable by
OTA Requestors.
Since the ACL attribute contains a list of ACL entries, writing of the attribute
should not just contain the values for the new entry. Any existing entries
should be read and included as part of the write. Below is an example of how to
write the ACL attribute with two entries:
```
out/chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": [{"cluster": 41, "endpoint": null, "deviceType": null}]}]' 0xDEADBEEF 0
```
- Entry 1: This is the original entry created as part of commissioning which
grants administer privilege to the node ID 112233 (default controller node
ID) for all clusters on every endpoint
- Entry 2: This is the new entry being added which grants operate privileges
to all nodes for the OTA Provider cluster (0x0029) on every endpoint
In the example above, the provider is on fabric index 1 with provider node ID
being `0xDEADBEEF` on endpoint 0.
## Current Limitations
- Synchronous BDX transfer only
- Does not check VID/PID
- Only one transfer at a time (does not check incoming `UpdateTokens`)