Ar71xx to ath79 remote upgrade Archer C7 v2

First of all, I'll say "Thank you" to the developers and maintainers for continuing to work on and make available the OpenWrt software.

Now the question.

Is there a relatively easy way to remotely perform the upgrade from 18.06.6 to 19.07.0 or later?

I am responsible for some Archer C7 v2 devices that are long and expensive journeys away (round trip is two days). I understand that it is recommended not to retain settings when performing the upgrade - but the issue for me is that I am not local to the routers I would like to upgrade and there is no closer technical support available. I know this is not an ideal set-up, but one can't always choose.

If the upgrade can be tweaked by me, possibly by building a new image, so that SSH and/or https (Luci) access via the WAN (which might also need dynamic DNS as the WAN IP address might not be static) can be carried over, then I am happy to build the rest of the config, assuming I can gain access.

This may already have been thought of, solved, and documented somewhere: if so, I apologize for not searching diligently enough.


You can build your custom image with custom configs and upgrade it with mtd write. Build your image with custom config, just to enable remote access to router. Test it locally initially.

1 Like

Generally, it is not recommended to do this remotely. However, if you have a VPN (that is not installed on the device you wish to flash) or the ability to remote-in or screenshare to a system on the same network, you could run the install that way. Keep in mind that the flash process (along with not keeping settings, which is the recommended upgrade method) will set the device back to defaults with wireless disabled, so you may not be able to reconnect if the default config is not right for your network.

You can build a custom image with the appropriate settings 'baked in' so that after the flash operation completes, the "new" default configuration works for that environment. However, you should test this first -- ideally you'd have a 'development' device locally (the same exact model) to verify that everything works as expected.

Another approach would be to work with a spare device locally, get it flashed and pre-configured, then literally ship it to the remote location and have someone do the physical installation.

If you are going to attempt to do a remote upgrade, it would be a good idea to have one or both of the following available:

  1. a person who is physically local to the routers that are remote from your perspective. This person should either be knowledgeable about OpenWrt or able to execute directions that you provide (i.e. over the phone) so they can be your eyes and ears on the other side. You should also be comfortable enough to be able to work 'blind' as you guide them through setup or troubleshooting steps.
  2. An alternate means of connecting to the remote network and that router so that you can perform admin/configuration/troubleshooting tasks as necessary.

Be careful as you might just end up making that long/expensive journey.

1 Like

Another solution would be to ask someone who is there already to have them connected LAN to LAN with a other router you can have remote access to.

mtd write can be dangerous.

Thank you for the replies. I will have to go down the custom image as described by psherman: essentially the far ends are 'IT-illiterates' with no secondary WAN connectivity to their local LANs. I do have exactly the same hardware centrally that I can experiment on. I will have to allocate some time to this...

On the wishlist for the future, I would like OpenWrt (on hardware with sufficient storage) to be able to have two images so that you download the new image, hit the 'go' button, and the router swaps to the new image, and waits with a timeout timer running for you to log in and confirm you have access. If you don't log in within the timeout period, it reverts to the old (working) set up and you can try again later with a revised new image. It would be a nice feature to have, but might not be compatible with the OpenWrt ethos of running on low-end hardware.

1 Like

That is not (just) a question of 'sufficient' storage, but of OEM bootloader support as well. There is a handful of devices which support this feature already - and yes, it is a nice one to have.


Thanks for that. I shall have to look into that selection of hardware and see if I can use it.

@Limentinus - one other thing to consider... do you really need to perform the upgrade in the near future? You mentioned that you have 18.06.6 installed on the remote routers. That is the most recent official release of 18.06, just 4 days ago (Jan 9, 2020). As such, it has the latest security patches. I would imagine that this is at parity with 19.07.0 in terms of security since they were released within days of each other.
So maybe it isn't worth the risk of performing remote upgrades unless you actually need to be running 19.07 on those routers. You could postpone the upgrade until the next time that you will be making the journey to those locations, and do it in person with the latest at that time.


You are quite right. Waiting until 19.07 has had one or two point releases to iron out the inevitable bugs on the move from ar71xx to ath79 is sensible, but I like to 'be prepared'. There is also the minor issue that I might not be able to get to all the remote sites in a reasonable timescale. I can use the time usefully to experiment with writing a custom image that leaves a secured ssh port open for me to get remote access. I'm sure that will be a rich learning experience.

Since it is a NOR flash you can image the flash on a working device of exactly the same model then use it as a sysupgrade on another router, which will become an identically configured clone. I would only attempt this if you have another router of exactly the same model at home to set up and test and produce the upgrade.

Once your "master" router is running what you want, cat its "firmware" partition to a file, scp it out of the router and run sysupgrade -F -n with this file on the other one. It is not necessary to use mtd write directly.

1 Like

Also consider a VPN as an option. There are a bunch of options here, but my new favorite is WireGuard which is really easy to configure, very fast, and pretty lightweight. You could make that part of your custom image.

Of course, a VPN doesn't make remote upgrades any easier/safer (it would, in theory, be the same risk level as you'd have with pretty much any other remote upgrade, provided you have an image that will (hopefully/ideally) come up in your desired state of configuration), but it does make general remote admin easy and secure.

Thank you - that is useful to know.

WireGuard is something I want to play with. As it is, I use ssh for remote management, using both the CLI, and the ssh -L option to redirect http so I can be lazy and use LuCI.

In case you don't know of that wrinkle

ssh -p22 -L 10001:localhost:80

While that is running in a terminal you point your web-browser of choice at localhost:10001 and you get the remote router's LuCI login page. The http session is carried securely inside the ssh wrapper. You can set up the remote router to use whichever ssh port you like: you are not restricted to the standard port. Just remember to configure both the ssh server AND the firewall for the non-standard port-number, otherwise you have a long and expensive journey in your future.

1 Like

if you had a few devices... it might be worth looking into usb booting...

I can plug in a usb try a release / setup... any issues and just remove the stick... once things are sorted you can then flash an IB generated .bin with confidence... ( or keep running custom builds on usb )... YMMV depending on the device / oem featureset / port availability / development experience ...