[Feature Request]: OTA over LoRa

[realtag-github]

Platform

Cross-Platform

Description

I had an idea about how to do LoRa OTA. I don't know if it is feasible though.

1. Cryptographically sign firmware binaries. Allow to configure what cryptographic key-pair to accept.
2. Split partition microcontroller into two. Similar to how wifi OTA for esp32 works.
3. Store slow LoRa OTA broadcasts into second partition to start assembling firmware out of chunks. Similar to how torrents or bitcoin blockchain sync work. (Too computationally heavy for microcontroller?)
4. Have a mechanism that can request chunks from specific node(s). Store OTA firmware on the second partition on the sender node. OTA would be cryptographically signed by Meshtastic, but allows custom key to sign.
5. Allow nodes to not re-broadcast this type of traffic or limit it only favorite nodes.
6. Have a rate limit of this type of traffic on every node. If network is too busy then de-prioritize it.

Maybe I missed something, but I would like to start this discussion. Maybe my idea is too difficult or too computationally heavy for the microcontroller. But to me it looks like it could work.

[garthvh]

Doing firmware updates over the mesh is just not feasible without destroying the mesh for everyone.

[b8b8]

#5870

Your best bet is maybe Wifi HaLow paired with a raspberry pi.

[realtag-github]

I am already at a point where updating firmware on some of my nodes would be a bit annoying. I gave some radios to friends and co-workers. They agreed to have them running, but I don't wanna keep asking them bring it back for a reflash. @b8b8

RPI setup could work but it would make it bulky and I would still be limited by range. Some of those radios are just within lora range but physically they are far away from my own nodes.

[CryoRig]

Just an Idea, not sure if thats programmable or if the hardware is even able to do this...

What about a "public" update?
have a setting which enables/disables said "public" update per node.
(i don't think one for receiving and one for sending updates is good as then you would have the same issues as with torrents: bunch of leeches and no seeders...)

Now if someone in the mesh has a newer version than other nodes, it could slowly (over hours or days with long pauses) send the update to the older firmware nodes, as this would basically be multicast it would also mean that multiple nodes could get the firmware with time.

What i don't know is if thats even possible.
the update would have to be held in memory/flash while the receiving node gathers all parts/packages, then reassembles it and, ideally, hashes it to make sure nothing got corrupted.

Also the bootloader has to be able to update/reload the firmware.

Edit: just noticed that most of what i wrote is very similar as OP, sorry about that.
But my point should still be valid if we just do this very slowly and let nodes "opt-out"

[realtag-github]

The firmware can be signed by the Meshtastic private key. Each node would just have to verify using Meshtastic's public key that the firmware was signed by them.

[CryoRig]

true, i did not think about the different firmware builds
Maybe it would be possible to build some kind of tag/number per type into the message which enables the receiving device to differentiate the firmware/build, this way the devices themself could decide to use the firmware or not?

It would also mean that there is more traffic in generall per update...

[Ryu945]

Now that I think about it more, that key verification could allow for the code to come from a non internet connected node. It would need to be the same device type.

[realtag-github]

The firmware code can be implemented in such way that the portion of it is always the same for all hardware variants no matter the hardware. It can be like scripting, maybe some things can configurable in such manner without having to modify the entire firmware. Maybe this would also allow to reconfigure the node over Bluetooth or Wifi.

[CryoRig]

so something like this? the author describes delta updates via OTA
https://thinkty.net/projects/2023/05/07/delta_ota.html)

[Ryu945]

Couldn't internet nodes give internet access to every node in the area and slowly deliver the update through spare bandwidth? Nodes would pull from the official github only.

[vk496]

Some nodes could be on top of mountains.

Going there to perform an update is worse than spending a month sending firmware over LoRa

[vk496]

I Implemented it in Meshcore.

meshcore-dev/MeshCore#2864

If any dev here is interested, I can do the same for Meshtastic (I would like to discuss technical details, so the solution would be interoperable between Meshcore and Meshtastic. If would really appreciate if someone could ping a dev for this)