Hello,
is this possible to erform remote firmware upgrade via web ui upgrading version 19 to versione 23 ?
Thanks in advance
B/R
"Likely not" is the basic answer, especially as you did not even reveal which router you are talking about...
it is my own gateway microchip sama5d based processor where i've ported from source OpenWRT v.19.07 and now i would like to step on v.23 but i need to remote upgrade the gateway on field.
This thread may be of interest to you as a general discussion about upgrading across multiple major release versions. From the sounds of it, you've been porting your own special builds, so that could add more complications... hopefully you've proven that your builds work as expected on identical hardware that you have locally.
Personally, I would recommend against attempting the upgrade remotely, unless you have someone on-site who would have the necessary equipment (ethernet connected computer, sometimes a serial USB adapter) and is either directly knowledgable about routers and OpenWrt, or can assist you over the phone or similar by following precise directions should something go wrong. Further, if this is the main gateway for that remote site, it will be important that there is some alternate internet connection (or method) by which someone on-site could download any necessary files and communicate with you.
Keep in mind that the config files from 19.07 are not compatible with 23.05 -- there have been several significant changes that will necessitate configuring from scratch. As such, you may want to consider baking-in all of the required packages and configurations to ensure that the default state is as desired.
Before making any attempts at this, make sure that you have weighed the risks/benefits of a remote upgrade (including the possibility that you may cause the internet connection to go down, if applicable, and need to travel to fix it).
1 Like
Anything is possible. Just be prepared to visit the remote site.
2 Likes
as far as i know v. 19.07 branch is now closed and is no longer updated. So all the functionality and also the security patch are not updated.
If remote software upgrade is not suggested how can you update the functionality and security of a router/gateway in version 19.07 on field without flashing it from scratch ?
Thanks
This is correct.
Two things to discuss:
- remote upgrades
- upgrading across multiple major versions
On the first topic -- remote upgrades are never really recommended. But given the appropriate conditions, it can be done. It is usually not terribly risky if there are:
- no major architectural changes that would require a reset-to-defaults (for example: ar71xx -> ath79, swconfig -> DSA, significant changes to the flash partition strategy or UBI partitioning, etc.).
- No major changes to the config syntax, and for any changes that have been implemented, the new version would need to be able to parse and 'fix' the deprecated syntax/methods. This way the config can be carried forward from the previous version.
- No post-upgrade package installations required. This can be addressed by building custom images, or more recently with the Attended Sysupgrade process.
Those conditions are not exhaustive as there could be other reasons that an upgrade might not be safe/recommended remotely, but I'd say that these are the most significant ones you'll encounter.
Then there is the issue of upgrading across major versions. Usually n-1 to n is supported (i.e. 22.03 > 23.05), but not n-2 and beyond. In most cases, the physical upgrade will work, but the config files will not be guaranteed compatible (or at least not tested to be parsed and migrated properly), so it becomes an 'at your own risk' type of operation. You're looking at 4 versions (19.07 > 21.02 > 22.03 > 23.05), so this is almost certainly not going to work.
Have you ever done a remote upgrade of this device in the past (even for service releases)? how are you connecting to the device to run the upgrade in the first place? How far away is the device and/or how difficult would it be to arrange travel (pre-emptively, or in an emergency)?
recap of my situation:
- Gatewyay HW based on Microchip SAMA5D31 SoM , 256MB RAM ,256MB NAND FLASH, SD CARD, USB connected LTE modem, openvpn
- Custom OpenWrt 19.07 built from 19.07 snapsht around 3 years ago
- Some of this gateway are presente on field
- Too expansve perform upgrade on site
Needs:
- update the hw above to the last OpenWRT version due to functionality and security patch (packages/kernel ....)
- up to now only my OpenWRT application package has been updated from remote using opkg install procedure. No remote firmware upgrade
- I saw that LuCi interface provide a interface to download image and upgrade and i saw this woking also on other OpenWRT router. I would like to use this method
I hope I am not bringing this thread from a sophisticated level too far toward a novice one, but these questions:
-
If the syntax changes between adjacent versions (e.g. v19 and v21, and again v21 and v22) are documented, where are those documents?
-
One way to find out about syntax change may be to have both versions (e.g. v19 and v21), to use LuCI in each to do the same thing (e.g. create a static lease), and compare the resulting stanzas in the respective config files. If that makes sense and if I wanted to do that in a virtual machine (e.g. in VMware) running OpenWrt, where would be the OS iso? For example, is it one of the files here: https://downloads.openwrt.org/releases/23.05.2/targets/ath79/generic/ Could it be llvm-bpf-15.0.7.Linux-x86_64.tar.xz?
-
Once I get to a VM running OpenWrt, could I experiment with Wifi setups? Of course, my VM won't actually generate a signal (unless I rig it with some hardware), but the question is could I mess with Wifi configs just to see?
Here's a totally random idea from a complete novice. Please take it for what it is worth, which may not be very much.
You might have one of two aversions. 1. I don't want to fly to my remote site. 2. I don't want to reconfigure this router from scratch.
If we consider only 1, how about: (a) strip your present v19 router of all configurations except for those needed for remote access (these may be just an open SSH port on the WAN side), thereby minimizing the probability of changed syntax soft-bricking your router > (b) incrementally upgrade v19 to v23 (incrementally: via successive flashing of major releases per advice above) while each time keeping the settings (i.e. those needed for remote access) > (c) once at v23, enter the (rest of the) old configs but in new syntax.
Of course one could brick the thing even at stage (c) by entering some incompatible configs I believe. The remedy against that may be to replicate the same physical setup at home and test everything there before doing it to the remote machine. Again, a complete novice idea.
I suspect you'd need to scrub through the git commits. They're often small things for any given release (barring major changes like swconfig to DSA), but they become larger in aggregate across multiple release versions.
This can certainly work, but you'd need to ensure that you cover every possible config option, so it could be pretty tedius.
Doing this on a VM would not necessarily be representative of what you get on bare-metal hardware. Depends on the specifics, though. For example, hardware with built-in switches, wifi, bridges and vlans, etc. The stanzas that change for the configuration related to the hardware would not be captured by playing with a VM. But if you want to know how to run an OpenWrt VM, look no further... here is everything you need to know.
Generally, no... this won't work. IIRC, there are some tricks to getting wifi to work, but its not even remotely the same as running on bare metal.
Even this may not be sufficient to prevent the risk of a soft-brick. And if remote access gets lost along the way, you'd be in a tough spot.
This isn't always a good idea... it has been discussed a lot lately. VPNs are better suited for this. But, even this method would only work if the device has a public IP and that public IP does not change.
What happens if the first one or two work fine, then the third soft-bricks because of some combination of factors that has not been tested/explored?
I'm not saying it's not possible, but I'd treat a remote upgrade as an option of last resort because of the relative risks of soft-bricking or otherwise encountering problems. Even more so if the device is critical to internet connectivity for the remote site and/or other services there.
1 Like
A VM can semi-accurately[0] replicate an x86_64 system with emulated hardware, it does not tell you anything at all about the more prevalent mips- or ARM based targets. Switches and their setup can't be emulated (neither swconfig nor DSA) and, as psherman noted, wireless is a totally different topic altogether, so the system behaviour and their configuration is totally different from what you'd see on real non-x86 hardware.
--
[0] the typical virtualization environments emulate a rather generic -bare bones- x86 system with multiple virtualized- or emulated network cards. The configuration for this is likely rather close to that of real-iron x86 systems, so that aspect you can test (for x86 only), beyond that you'd just have to 'trust' that the real drivers needed for the physical hardware do their job. There is no way at all to come even close to emulating mips/ ARM systems, as the really existing hardware is far to different from the emulated models used by armvirt/ armsr or malta, those are good enough to test userspace programs, but pretty much nothing about the hardware interaction itself. As mentioned, there are no sensible ways to test onboard switches (a major aspect for OpenWrt configurations) or WLANs (hwsim does not help you that much and pass-through of real WLAN cards into the VM is… ${not_very_reliable})
2 Likes