[RFC]: OTA via MQTT

[slaff]

OTA over HTTP(S) will work most of the times but it has some overhead. A lighter and faster solution would be to allow OTA over MQTT(S). This can be implemented in the following way.

Communication

• OTA client connects to a central MQTT server and subscribes to a topic based on its current version. For example the client subscribes to /update/rom/4.3.1. OR /u/r/4.3.1 so that the communication is as short as possible.
• If there is no update needed the MQTT server should return one byte with value 0.
• The client should wait up to a limited number of seconds to start receiving a message on the subscribed topic. The timeout can be 10 seconds. If the timeout is reached the client should assume that there is no update.
• If there is a new update then the binary data will be sent directly as a response. The MQTT protocol allows messages with a maximum size of 268435455 bytes approx 260MB.. This should be perfectly enough for a device that has maximum 1MB available for an application ROM. The message should contain: varint for the binary data length followed by the binary data itself. Simple Length-Value (LV) encapsulation.
• If the client supports compression then a new topic should be used. For example /update/rom/compressed/4.3.1 or shorter /u/r/c/4.3.1.
• If the client wants to update also its file system or other part, as for example bootloader, configuration, etc then it should subscribe to /update/data/4.3.1 or /u/d/4.3.1.

Security

• The communication can be secured using standard SSL.
• To proof that the server is the correct one: The MQTT clients should pin the public key fingerprint on the server. OR have a list of public keys fingerprints that are allowed.
• To proof that the clients are allowed to connect: Every MQTT client can have also a client certificate that is signed by the server. ( See MQTT Mosquitto broker – Client Authentication and Client Certificates ).

Operation

Roles: super user, anonymous user and admin. (See Mqtt authentication)

• Adding new version: There should be a superuser that can write to these topics a retained message. The message is encapsulated using the LV schema mentioned above
• Fetching new version: all clients should be able to access the update topics without authentication (as anonymous users).
• Anonymous users are NOT allowed to write messages to any topic.
• Anonymous users are NOT allowed to read any system topics.
• Admins are allowed to read system topics.
• To limit also the number of clients connected a SSL client certificate should be required.
• The can be also rate limiting per client. (Example: Maximum 3 checks per hour, Not connected longer than 2 minutes.)

Possible software for the server side:

• MQTT server: VerneMQ or mosquitto.
• Infrastructure builder: dojot

[slaff]

Final version is implemented in SmingHub#2269.