Re: Zephyr DFU protocol

Carles Cufi

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown@...]
Sent: 28 August 2017 17:59
To: Cufi, Carles <Carles.Cufi@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr DFU protocol

On Mon, Aug 28, 2017 at 02:43:27PM +0000, Cufi, Carles wrote:

As I already stated, this is not about choosing the only protocol
available for updating images in the target device, so implementing
standard USB DFU is definitely something that we want as well. That
said, I would also be in favour of having the future management
protocol run over CDC ACM, for 2 reasons:
One other protocol I just realized is already out there is lwm2m.
There is starting to be some support for it in Zephyr, it works over
other transports, supports device management, and has support for
firmware update.

The eclipse foundation has a couple of implementations (wakaama in C,
and Leshan in Java).
I just read through the highlights of the spec and indeed this matches relatively closely the concept we are trying to push here with a "management" protocol. After looking through it a bit here are the problems I see:

a) Complexity: By reading through the specification[i] this looks like a pretty complex protocol to me, which in many cases might be a drawback to users wanting to reduce ROM and RAM size. This is particularly important for very constrained devices that only need to send some sensor data over BLE for example
b) Suitability for other transports: The specification clearly states 2 main transports: UDP and SMS. While adapting this to other transports would likely be feasible, the protocol doesn't look designed for it
c) Model: the protocol seems to rest on the basis of a "pull" model, where clients are the target devices. For the reasons stated before, this might not be suitable to simple UART, BLE or USB CDC ACM usecases.

That said, the protocol does match the Newt Manager Protocol quite closely when it comes to supported functionality and purpose. My vote here would be to have support for both, because I do not think running LWM2M over UART or BLE is a good match for tiny constrained applications that only require simple firmware updates.

The approach that was demoed at the last Linaro Connect was pull
based, and essentially had the firmware living on an http server. It
had the advantage of being fairly easy to implement with existing
code in Zephyr.
The problem with using a pull-based protocol is that it is less
portable to non TCP/IP transports as I see it, since it requires the
target device to initiate the transaction. Are you implying that you'd
prefer the Zephyr "management" protocol to be pull-based? We're
definitely open to discuss that at length. Also see the section about
the Newt Management Protocol over OIC/OCF, which implements "push"
over TCP/IP, which could be an alternative for the Linaro usecase.
I agree that the pull approach isn't really all that great, but it was
easy to implement. It does make management of the upgrade server a
little easier, though. I'm not sure how well a push-based protocol
scales to a large number of devices.
I honestly have no idea whether the push model would scale for large deployments, but this brings an interesting question, which is what sort of device are we targeting here:

1) The simple device which is never connected to the internet directly and does not even have a TCP/IP stack, but rather only a GATT-based BLE connection to a mobile phone, table or computer. Among those there are mice, wearables, sensors and monitors, etc.
2) The slightly more complex device with (almost) always-on TCP/IP connection to the outside world, perhaps over 15.4, Thread, BLE over IPSP or any other technology

I think the Newt Manager Protocol was designed for devices closer to the 1) model. LWM2M and similar protocols target rather b). Those are quite different in nature because a) requires a device to specifically connect to it and send an image with that purpose (say for example a sports band such as Fitbit or similar), whereas devices of the b) kind can keep polling regularly to determine whether a firmware update is available. I do not think we can realistically cover both with a single protocol unless we "force" one of the 2 models to work in the other circumstances.

Any idea how Android or iOS handle this? I would guess that both are
pull based, since that would otherwise require the vendor to have a
server that keeps track of every device out there.
Not sure about Android, but I am pretty sure that iOS devices keep a TCP connection permanently connected to an Apple server, through which all "push" notifications are sent, be it software updates or messaging notifications.

I agree that newtmgr protocol seems to be the best fit for us. It's
serial model would even fit in fairly well with the Zephyr shell,
since it wraps the packets with a control-character + base-64 packet
+ control character, which the shell seems to have partial support
for already.

It does, I didn't mention that to avoid extending myself too much, but
it's also a very nice feature I find.
One other thing we should consider is the security of the upgrade
protocol. Mcuboot has signatures to validate images, so that would
prevent rogue upgrades, but if we have a management protocol, that
should probably also be secured via some means.

It is likely that something like lwm2m is going to be implemented for
Zephyr (code is there, and work seems to be happening on it), so we
should decide if we want to push the newt management protocol as well.
Agreed, and it's not an easy call. The two options I see after your remarks and looking a little bit more into LWM2M are:

- Use LWM2M for everything, including DTLS for security and adapt it somehow to the simple "push" model
- Use LWM2M for the "pull" model, and then Newt Manager Protocol for the simple "push" one, with security in the latter being provided by the transport itself (SMP in BLE, and the simple fact that you need to manipulate the device physically for UART).

While having one single protocol would definitely be a boon, I am not sure LWM2M will fit the bill in terms of RAM and ROM requirements, and we still need something for the UART recovery mode in the bootloader, which will probably end up being the Newt Manager Protocol since I don't think we can fit LWM2M into a bootloader.

Additional thoughts welcome.


Join to automatically receive all group messages.