Avoid accidental downgrade (=bricking the device)

tbnobody / OpenDTU

Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters

GNU General Public License v2.0

1.81k stars 507 forks source link

Avoid accidental downgrade (=bricking the device) #1927

Open broth-itk opened 6 months ago

broth-itk commented 6 months ago

Is your feature request related to a problem? Please describe.

Well, it happed to me: I wanted to upgrade to the latest release but somehow I selected accidently an older version from the downloads folder. The device rebooted and was obviously not available anymore.

I had to perform a complete reflash with the factory image and restore the configuration from backup.

Describe the solution you'd like

This problem might be easy to fix but some OpenDTU units might be installed in a not-so-easy-to-reach location.

I would like to suggest to

Include some kind of version number (integer) in an fixed address of the image, best somewhere at the beginning
Running OpenDTU checking if own version > upload version, then discard
If upload version is newer, proceed with the update as usual

Lets discuss the impact or maybe other ideas which would help. Thanks!

Describe alternatives you've considered

No response

Additional context

No response

tbnobody commented 6 months ago

I don't like the idea as it would prevent all users to downgrade if a version contains a mistake.

MetaChuh commented 6 months ago

@broth-itk

just for curiosity: which older version did you flash, and was it the correct version for your board ?

i ask, because i can not reproduce a brick if i downgrade to a lower version within the scope of the last few months. it would be nice and maybe helpful, to hear which version you used, and which esp32 type it was ment for, as well as on which esp32 type you flashed this version resulting in a temporary inoperable state (not brick)

after that you can close this issue.

thanks & greetings, metachuh

broth-itk commented 6 months ago

I'm not advocating against the possibility to downgrade. Don't get me wrong. I just want to avoid the device getting bricked for some reason due to a mishap.

@MetaChuh The unit was running v24.3.31 and instead of installing v24.4.12 I uploaded v23.12.18

broth-itk commented 6 months ago

What about a new version field which indicates the "generation" (including memory layout, configuration file format and so on):

Upgrades and downgrades within the same generation is possible.
Upgrade to newer generation only
No downgrade to older generation

tbnobody commented 6 months ago

The downgrad to this version failed because of a bug in the upstream esp32 framework. Feel free to create a PR implementing this checks. (and keep in mind, that memory is limited) But then you also have to check every release and check to which previous release it's possible to downgrade. I don't have the resources to do this.

broth-itk commented 6 months ago

This is not meant to be a "Arbeitsbeschaffungsmaßnahme" (work creation plan).

If there was an efficient way for the software to detect an older version, a message like "warning: attempting downgrade, are you sure" is sufficient. ... or a checkbox "allow downgrades" in the Firmware Upgrade section.

Any other ideas?

MetaChuh commented 6 months ago

@broth-itk

many ideas: eg. instantaneous solutions:

clear the download folder of older downloads, before using any update files from there, or at least rename the files by adding the version number to the file name.
perform an upgrade via usb using the Web Flasher in Upgrade Mode (no downloads are needed)

possible code solutions:

the blocking has ideally to be done at the js side, e.g. by regexing the file name, which must then include the version number, compared to the own version number. any post upload method would appx require twice the space.