[feature] Firmware update through openwisp-config

[okraits]

The possibility to update the firmware of a device is an important feature. Without that, bugs and security issues in firmwares can't be fixed and features can't be added.

I implemented a prototype to be able to do firmware updates with openwisp-config:

https://github.com/TDT-AG/openwisp-config/tree/tdt-firmware-update#firmware-update

This can also be triggered by openwisp-controller by changing the target firmware version in the option firmware_version. It still needs an implementation of controller-side firmware handling (firmware-upload to the controller, mapping of firmware files to specific devices, static firmware file serving).

This is also meant as a prototype for a client-side implementation of a future feature of openwisp-controller: openwisp/openwisp-controller#31

[nemesifier]

Oliver, I share the fact that it's an important feature, but it's definitely out of the scope of openwisp-config: this module is focused on dealing with managing the configuration of a device, we should not add logic that is related to different features here, that's a very dangerous path to follow.

The right approach is to create a new package and if it's necessary that they share some parts, have some shared logic between the two (but it's entirely possible that may not be needed, we have to see).

I see that the logic you have added is not coupled with the logic of openwisp-config so that's good, I would proceed and create a new package for this.

There are other examples of this practice, although these modules are less widely used than openwisp-config due to the fact that they are very specific to the use case of public wifi that Cineca followed:

• https://github.com/openwisp/luci-openwisp
• https://github.com/openwisp/openwisp-netcheck

Use case a part, that approach is the right one, have each package solve one specific problem.

[okraits]

I added my changes to the openwisp-config repository mainly for practical reasons. This is meant as a prototype or proof of concept on how to do firmware updates easily and straightforwardly by using the existing infrastructure. What do you think about the concept in general?

This could of course be packaged as a package depending on openwisp-config or as a standalone package.

Thank you for mentioning those packages - I was not aware of them.

Still missing is of course a corresponding django app for managing and serving firmware files for all kinds of devices.

[nemesifier]

The concept is promising, I would only try to think about a simpler URL.
I think the information that an openwisp server implementation would need are:

• device model
• organization
• a category (so we can support having different firmware types for each org, for example you could have a firmware for a DSL router or a BGP router and another firmware for wireless devices)

With those 3 fields I think an API can figure out what image to return.

Although the URL you are using now can potentially work also without a server running, you could just place the images manually there when you have them available and start testing these scripts, which would be a good thing to do.

Some form of authentication may also be needed. Maybe now while you are testing it you can do it with simple HTTP basic auth, in OpenWISP we can use a token or why not reuse the device UUID and key.

[okraits]

Yes, I thought about how to determine the URL, once again. You're right. IMO, from top to bottom, this should be the information used to choose a firmware file/URL (from the point of the server):

• organization: firmware management should of course respect multi-tenancy - different organizations might have different firmware images for the same device
• device model: the exact hardware model of the device
• image name: this might be what you meant with category: there might be several firmware images for the same device, with a different collection of packages and different default configuration (for example for different customers) - we have /tmp/sysinfo/image_name similar to /tmp/sysinfo/model

Yes, I already did a successful firmware update via openwisp-config by hosting the firmware with a simple python static webserver :-)

For authentication, using the existing means (UUID/key) would be a good thing.
I think this depends on how we go on with this feature and the connections feature. Right now this is just a prototype. Should we keep it separated from the connections feature or leave it for now as it is and go on developing the connections feature and integrate it with that later?

[nemesifier]

@okraits that's great that you tested the concept successfully!

Should we keep it separated from the connections feature or leave it for now as it is and go on developing the connections feature and integrate it with that later?

I'm not sure I fully understood this question, I try to reply but I may have got it wrong, this are the different pieces of code I see that interact with the firmware upgrade feature:

• connections module (openwisp_controller.connection module (SSH connections) openwisp-controller#31): this is what allows openwisp to access devices and trigger configuration updates without waiting for the daemon to do it's periodic check; I think it's ok to keep this piece of code in openwisp-controller, I don't see advantages of separating it
• firmware upgrade module: this module defines some new models and admin sections to manage firmware builds and related images (divided by firmware category, each category belonging to an organization in order to have multi-tenancy on this feature too), this module also defines some classes that specify how to perform the upgrade (when using the push strategy, which is based on the connections feature), initially we'd have only the OpenWrt upgrader class. We can add the API endpoints to allow downloading firmware images here for the pull strategy. I see advantages in separating this into a new module because it makes automated testing easier, in my initial prototype I hacked a bit of code into openwrt-controller but that caused a lot of issues with the admin tests of openwisp-controller, there were no real breakage of functionality, only broken tests for a purely technical reason (when you add more inlines to an admin class, tests that send post data stop working unless updated to include the data of new inlines)
• firmware upgrade OpenWRT package to implement pull strategy

[okraits]

@nemesisdesign Ok, I didn't explain what I meant, so I will elaborate:

• on the server side it's clear that we need two separate modules:
  • connections module in openwisp-controller to be able to actively connect to devices to trigger actions
  • firmware upgrade/management module like you explained
• on the client side I can think of two ways on how to proceed:
  • package my prototype now (after small improvements) as an addon package to openwisp-config (it basically contains the hook script openwisp-update-firmware and the url example script firmware_url_script - we could also merge the 2 scripts if we find a way to generalize URL handling so it matches common needs)
  • leave the prototype now as it is and merge it later into the client for the connections feature (I assume you want to implement a separate client for the connections feature independent from openwisp-config - but I also think that the firmware update feature should be independent from the connections feature and thus be separately packaged)

What do you think?

[nemesifier]

Closing this as the firmware upgrader module is now available: https://github.com/openwisp/openwisp-firmware-upgrader