Upgrading from OpenWrt 19.07 remotely

My uncle is on openwrt 19.07.7. I need to get him to the latest 21.02 and I do have his converted and upgraded files because I own the same router. We are 2000 miles away at any point but I dial in. I have 100% control of the files on his router at all times and backed up on a flash drive.

My main concern is wireguard version mismatch.

What is the best way to accomplish this {for my uncle}? I dont mind the work, but my uncle minds the downtime.

Not sure what you're referring to for "converted and upgraded files", but in case you're not aware, there have also been changes due to the move from swconfig to DSA in 21.0.x

As a result, configurations are not upgradable for the following targeted devices...

ath79 (only TP-Link TL-WR941ND)
bcm4908
gemini
kirkwood
mediatek (most boards)
mvebu
octeon
ramips (mt7621 subtarget only)
realtek

If your device target is included, you'll need to re-configure from scratch.

kmod-wireguard uses the 5.4 kernel.

You should be able to pre-download the Wireguard packages...

What happens if you get disconnected at any point during the upgrade?

Sorry for the semi off-topic aside,

Please drop ath79 (only TP-Link TL-WR941ND) from your list, while technically correct (for h/w rev v2/ v3 only), it doesn't really matter in the grander scheme of things.

The TL-WR941ND v2/ v3 has been using DSA way before 21.02.x already (I'm too lazy to check, but at least 19.07.x and I'm pretty sure about 18.06.x as well; might have already been 17.01.x), courtesy of its legacy Marvell switch and therefore will continue to work with its old configuration just as-is. It was one of the first devices to use DSA drivers at all, way before luci knew about it. On top of that, the tl-wr941nd v2/ v3 -as a 4/32 device- isn't even supported by 21.02.x at all.

Disclaimer: I own a tl-wr941nd v2 myself.

Edit: just dug through old archived configurations, at least since master as of 2015-08-13 (can't find older configs at the moment), so using dsa -at least- since 17.01.x.

That came from @hauke's release notification for 21.02.0 -

Let's check if he's OK with amending, or dropping it.

Yeah. Don t do it unless you have a backup router in the location and a person capable of doing factory defaults on openwrt or hook up a serial console. For these reasons I ve kept one of my managed routers on lede 17.01 because the pandemic prevented me from traveling the 1400 miles

2 Likes

I did this for a while but there was a wireguard version mismatch around that version so I had no way to dial in. I travelled the 1000 miles and upgrade it to version 18 at the time. How do you still stay in contact with it using wireguard and keep your other local systems up to date?

I only perform upgrade when I'm physically near the device or have a person capable to carry out debug & restore operations on the other end (not available unfortunately for my personally managed devices - only for my professional ones)

1 Like

I won't carry out this operation and that makes me a little sad but I know it is possible because there is an upgrade function in every version of openwrt. If there were a list I could make that upon upgrade would run

opkg update && opkg install $list $list-renamed-programs

I could probably do it.

anyways the answer is probably no but I feel this could be easily fixed. an upgrade-assistant program or something. maybe im asking too much.

What if i setup the /etc/rc.local file to temporarily host opkg update && opkg install $list $list-renamed-programs then perform an upgrade to keep my config files (yes I meet the file requirements in /etc/config/dhcp and /etc/config/system to perform the upgrade to 21.02). upon reboot the router will download and install the programs. upon the next reboot the config files will take effect.

still risky - maybe you'll have more chances if you put the config on your identical device and test the procedure 2 or 3 times to make sure it's solid

I already have. It succeeded. im still wary about it.

I mean I can't be championing this idea? I'll make a program based on this and we can all upgrade versions with our latest software intact but should I be?

Expensive solution, but more foolproof would be to have 2 identical devices...

One gets shipped to your uncle, fully upgraded and configured.

He tests it.

If it works, he sends you the "old" device for the next version upgrade.

If it doesn't, he keeps the "old" device until you build new firmware yourself, with the included packages, fully tested.

You post that on OneDrive, Google Drive, DropBox with instructions on how to download it, and run it on the "new" device.

He still has the "old" device as a backup...it never gets changed.

1 Like

We actually did this before but he's retired and sold his house for a nice trailer so he is in any given trailer park in TN at any given time. I do have the spare tester router available and id send it to him if he ever gets an address.

I was trying to reply to a specific user but made a duplicate. sorry.

We do this solution and it works. He is in a travel trailer traveling now. The tester router could realistically have his config files and i'd have my tester router back but he is in a new zip code everyday. at least he takes the router i made for him seriously.

He could give you an itinerary, and ship it to the Post Office (with a Hold for Pickup option) at the nearest location where he'll be on a certain date.

He would either be waiting for it to arrive for a couple of days, or it will sit there for a couple of days waiting for him to arrive.

The best way to avoid package compatibility and settings problems would be to compile a tailored firmware with all needed packags included, and to include his config files (/etc/config, wireguard certificates etc.) as custom files to the build. Possible both with the full toolchain and the imagebuilder.

So, there would be no package install tasks for him.

Then it would only be about succeeding in the flash process itself. And that risk you can't avoid.

As you have the same router, you could also flash the compiled firmware locally first and test it, so that you can verify that the build works.

Perhaps look at the problem differently? This looks like a remote access issue, so if you access the device by another internet link you can keep a live connection while do the upgrade and reconfigure.

Have him setup a hotspot on his phone, connect to it via wifi or usb from his laptop and then Remote Desktop in, use the Remote Desktop to access the router and complete the upgrade.

A bit of stuffing around but if you’ve tested the upgrade process already on another device you should be good. This is how I support my remote family thru messed up internet issues

What happens if the connection drops at some point during the upgrade?

That’s the good thing with remoting into another pc, the remote pc will still be connected to the router allowing you to re-establish the connection and keep working