@ -22,6 +22,8 @@ This allows administrators to find devices with outdated bootloaders and helps t
\subsection{Common framework and build infrastructure}
The framework includes a build system, which allows to configure basic parameters for all devices, including, but not limited to, the Wi-Fi access parameters, the \textit{MQTT} connection settings and the updater URLs.
Each device requires to have the \texttt{UPDATE\_URL} option set to make the update work.
Skipping the option results in the exclusion of the code for update management during the build.
By sharing the same code, all devices ensure to have a common behavior when it comes to reporting the device status or interacting with the home-automation controller.
This eases configuration and allows to collect information about all devices at a central location.
The implementation of the update mechanism consists of four parts which interact closely: checking for updates, reprogramming the device, calculating and verifying the firmware signature and reconfiguring the boot process.
This sections describes all four of these parts in detail.
The build-time configuration was extended to include a new option called \texttt{UPDATER\_URL}, which is the base URL used to query the update server.
Each device requires to have this option set to make the update work.
Skipping the option results in the exclusion of the code for update management during the build.
The update mechanism is split into four main phases: checking for updates, reprogramming the device, calculating and verifying the cryptographic signature of the updated firmware, and reconfiguring the boot process to use the new firmware.
\subsubsection{Checking for updates}
Each device queries the update server regularly for the current firmware version and initializes the update process if remote and local versions differ.
To do so, the update server provides a file for each device type containing meta-information about the available firmware which consists of the version identifier and the signatures of both of the firmware images.
These meta-information files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\$\{DEVICE\}} is the device type name).
The meta-information file has a very simple line oriented, ASCII based format which is easy to generate and efficient to pars in the limited constrains of the embedded device.
The first line is the version identifier which can be an arbitrary string as the content is not interpreted semantically but only compared to the version identifier used during build time.
The other two remaining lines is the hexadecimal representation of the firmware signatures, one line for each firmware image.
Each device tries to fetch the meta-information file once every hour.
After the file has been downloaded successfully, the version identifier is extracted and compared to the version identifier provided during build time.
If the version identifiers differ, the update process is initialized; in cases where the download has failed, the update server or the network connection was not available or any other error occurred, another attempt will be made at the next interval.
In order to inform the IoT devices of the availability of a new firmware version, the update server provides a file for each device type containing meta-information about the latest available firmware version.
The meta-information file has a simple line oriented ASCII format, which is easy to generate and efficient to pars within the limited constrains of the embedded device.
It consists of the version identifier and the cryptographic signatures of both of the firmware binaries.
The version identifier can be an arbitrary string as the content is not interpreted semantically but only compared to the version identifier used during build time.
The other two lines in the meta-information file provide the hexadecimal representation of the cryptographic signatures, one line for each firmware binary file.
These meta-information files are provided by the update server using \textit{HTTP 1.1}\cite{HTTP_1.1} under the following path pattern: \texttt{\$\{DEVICE\}.version} (whereas \texttt{\$\{DEVICE\}} is the device type name).
Each device queries the update server regularly (initially at the end of the boot process and periodically once an hour) for the currently available firmware version.
It uses the \texttt{UPDATER\_URL} option to identify the update server.
After the meta-information file has been downloaded successfully, the version identifier is extracted and compared to the version identifier of the running firmware.
If the version identifiers differ, the update process is initialized.
In cases where the download fails, the update server or network connection is not available, or any other error occurres, another attempt will be made at the next regular interval.
In addition to the interval, a special \textit{MQTT} topic shared by all devices is subscribed on device startup: \texttt{\$\{MQTT\_REALM\}/update}.
Every time a message is received on this topic, a fetch attempt for the meta-information file is triggered and the process restarts.
This allows faster roll-outs of updates and finer control for manual maintenance.
Sven Reissmann
8 years ago