Using backup across architectures

The situation and problem:

  • TP-Link WDR3500v1 running OpenWrt 19.07.0-rc2 r10775-db8345d8e4. Users want to change the WiFi password, but they've forgotten the admin password. The router is the internet gateway in a rural area, acts as DHCP server for three other routers on the 192.168.2.x subnet. If it stops working, they will have to go to another town for internet. The users have little technical skill, and there is no backup file. I am far away in a big city.

Ideas for solutions:

  • Reset the router to defaults by using the physical reset button. WHY NOT: because reconfiguring the router (subnet, wifi) requires multiple steps that they would have to take while maybe disconnected from the internet. It's possible, but risky.
  • I set up a virtual machine on my x86 laptop, configure it with the correct values, and create a backup file. I send the backup file to the users, they download the backup file, reset the router to defaults, and restore it using a backup file that I made using the x86 virtual machine. Would this work?
  • Reboot into failsafe mode and change the root password. WHY NOT: Very likely to fail because the users are unfamiliar with command lines and everything else involved.
  • Any other ideas?

How to avoid this situation in the future:

  • It would be a good idea for the users to have a backup of a correctly configured system, so that any time they want to, they can reset to defaults with a physical button, login, and restore the backup. I know there are also options like giving me remote SSH access that depends on my SSH key instead of the root password.
  • What other options exist?

As admin password has been forgotten, the only options are failsafe or reset.

Reset sounds overkill. Why destroy all settings?
Just set the admin password and WiFi password.

Failsafe should work, and you should be able to explain the few commands needed. (Installing an easy editor like nano simplifies things.)

opkg update
opkg install nano
nano /etc/config/wireless

It would actually be also easy that they just set the password, reboot, and then you do the other editing with teamviewer or something similar.

If a tl-wdr3500 is sufficient for the internet connection in question, I'd suggest to keep a fully configured backup device on hand at the location (and yes, writing the admin password on a label underneath the router might not be a bad idea either, even if that makes any security minded person cringe).

Devices roughly equivalent to the tl-wdr3500 can be found new for ~25 EUR (used for even less, often with better specs), having spares makes sense for anyone - but even more if you have to support relatives over a distance.

As long the settings are just common settings which are shared across router architectures/models/versions this approach would work. But as soon as it comes to settings which are hardware related it would not work. E. g. there is a variable called "option path 'pci0000:00/0000:00:11.0'" for each radio in /etc/config/wireless which is different for each router model. So I would exclude at least wireless from backup. You can try strip the backup from those files.

Another approach would be working with an uci script. That could be copy and paste into luci command shell (I don't know if it still exist nor if its included in standard installation). For this you would not need any hardware related stuff.

You could build your own firmware including configuration already also.

Don't forget to configure ssh properly for future assistance. :smiley:

Config backups are not compatible between different models, even less between x86 (plain ethernet card) and traditional routers (with a software managed switch inbetween). Things that do differ massively are networks settings, switch configuration, WLAN, LEDs and more.

1 Like

Yes I know. I did that in the past already and it was working. It is dirty and you have to strip a lot. Without testing its not ideal. But for 2nd shot after password reset failed due to lack of knowledge/skills it is an option. Which I do not reccommend. :smiley:

Imho failsafe, mount_root and passwd is easier to explain than fixing up the incorrect network settings from another device, by far.

Of course it's much faster and easier. I was just trying to answer his question about his vm approach. It would not be my first approach. It costs to much time.

Thanks everyone for your responses!

Nobody there has a computer with an ethernet/RJ45 port, there are only cell phones. So I think this makes failsafe mode impossible. I see that TeamViewer host is available for Android, and while I'd prefer a free/libre software solution, remote control of a phone there could be very useful.

If we:

  1. Reset the gateway router to defaults with the physical button, so now it has DHCP enabled and is on the subnet.
  2. Connect via cable to another router in the community (that currently has wifi enabled but DHCP disabled and is on the subnet)
  3. Use a phone to connect to that WiFi. Will it get a DHCP-assigned address in the subnet, or will it be necessary to set a static IP?
  4. Browse to (the gateway), login, and reconfigure (either by restoring a backup file, flashing with a new firmware that I compile, or configuring via LuCI). At this point, TeamViewer or a FLOSS remote control of a phone there would let me perform the configuration.
  5. Note: Remote access could fail if there's another router with DHCP active on the subnet, which might be the case. The network goes: internet > house in town A > 20km wireless link > house in town B. So maybe it's safer to assume that's the case, and give them a backup file or new firmware, so they just upload one file and have fewer steps to get confused. The gateway we're talking about fixing is the gateway for town B, and there's a chance that the subnet in town A is on

I like this idea! The prices are a higher in Ecuador (USD 55 for a TL-WDR3500, although there might not be any left for sale), so maybe we'd use a different device. The three TL-WDR3500 currently in the network came from the US, where they're cheap and plentiful.

I think the current problem happened because someone there who knew the admin password logged in, then changed the admin password in a mis-guided attempt to change the WiFi password, but no one claims to have done this. Many of us knew the admin password, but now it won't work.

Ok, I'll try making a backup on a VM, looking at the result, and taking out device-specific stuff. I wonder: Will it let me define SSIDs? Or at least enable WiFi?

I would need access to the device, so it seems similar to restoring a backup, though I don't know.

I tried compiling firmware yesterday, and the build of 19.07.3 kept failing when it got to squashfs. Also, I couldn't find a clear explanation on the OpenWrt wiki of how to make the changes I want -- I found how to include files, but no explanation of how to make those files change the root password, enable WiFi, set the LAN subnet, etc.

I noticed OpenWISP2, and just watched a couple videos. I realize that setting it up in this case might be excessive, but seeing how easily the templates are created, I think something like that could be useful.

Yes! I imagine this means making a way to login that isn't affected by accidental changes to the admin password.

I appreciate knowing that this is an option, even if it's a dirty fix that might break things. Maybe making the backup will give me an idea of what files to include in a new firmware build.

How could I simulate the entire router in a VM? I think in VirtualBox I saw the option for mips, and given that I can simulate a system that runs Windows in a VM, it seems that making a virtual router that simulates a TL-WDR3500 would be possible. Any tips?

You can't.

While you can emulate arch (big endian mips in this case), there's no way to emulate (switch, WLAN, ethernet, etc.) the peripherals in a similar manner. Even a roughly similar setup, using supported (emulated/ virtio) hardware would result in a vastly different configuration (no, the tl-wdr3500 image wouldn't boot under emulation anyways, it's not generic enough for that).

It is actually easy to do. Use the image builder to spin up an image and use uci-defaults to setup the router. If you script all config and make it a part of the image, then a factory reset is actually a full restore to the original config that you embedded into the image. In other words, each router has its own sane config.

UPDATE: Command to change password:

/bin/sed -i 's/^root::/root:${HASHED_PASSWORD}\/:/‘ /etc/shadow

You do not need to. Each openwrt router using the same configuration format and the same command line uci tool to perform configuration. A while ago I got tired of merging config between different routers, so I automated the common config. Now when a router comes up and generates default network/firewall/syste/etc files, it then proceeds to run the configuration scripts (on the first boot only). Those scripts setup networks, interfaces, firewall zones, dns, ddns, etc. and by the time they finish, the router is fully functional with no user intervention.
The only thing I ask a user to do is to upload the image I sent them. I also disable "reuse configuration" in LuCI, so it is not even an option for anyone to keep the current config.

You can edit textfiles as you want as long you use uci syntax within config files.

e. g. /etc/config/wireless

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option ssid 'BLAH'

in a script integrated in own firemware image or the c&p approach it would look like:

uci batch <<EOF

set wireless.@wifi-device[0].channel='6'
set wireless.@wifi-device[0].country='DE'
set wireless.@wifi-device[0].hwmode='11g'
set wireless.@wifi-iface[0].mode='ap'
set wireless.@wifi-iface[0].ssid='BLAHLAN'
set wireless.@wifi-iface[0].encryption='psk2+ccmp'
set wireless.@wifi-iface[0].key='blahblub'
set wireless.@wifi-iface[0].wps_pushbutton='0'
set wireless.@wifi-iface[0].wpa_disable_eapol_key_retries='1'
set wireless.@wifi-iface[0].ieee80211w='1''
set wireless.@wifi-iface[0].wmm='1'



You could send them the text the content they just paste into luci gui which they can open with browser after reset over openwrt wifi which is open w/o password.

You could work with ssh keys only. Just disable password access.

@fantom-x answered already. If it fails just make a thread about. Maybe ppl can help here.

You mean that as of 19.07-rc2 (which is running) up to current release, in the default image, that when the router is reset, it has wifi enabled by default?

I see that by default, the Image Builder makes an image without LuCI, so it is not the same as the image I download from the device info page. I will include LuCI and see what I have to do for SSH.

Scripting vs FILES=files/
You mention including a script, but also making an image. I thought the purpose of making an image is to include the settings I want via FILES. You suggest including just one file (a script) instead of the config files? I don't understand the difference.

What is the c&p approach?

You can customize that by adding any package you want. It is all well document on the page I shared.

files/etc/config would be static config (but not portable)
files/etc/uci-defaults is for scripts to run on boot. Scripts get deleted if the finish successfully.

Ok, yes, I just started reading that page and see the explanation -- sorry for asking before reading thoroughly.

What I haven't found yet: Without having a running router, where can I find the default config for the tplink_tl-wdr3500-v1 profile? I'm sure it's somewhere in the OpenWrt source control repo, but I don't know where to look.

I ask because I want to make sure that the options I define with uci make sense.

EDIT: The closest I've found is;a=blob_plain;f=target/linux/ath79/generic/base-files/etc/board.d/02_network;hb=9a477b833ab2aea96b9eee55acb5f9e7b01b36d8

That I do not know. I always had physical access to the router before automating its provisioning. I would start with the default config (from a factory reset) and keep augmenting it with uci commands until it is all the way I wanted to be.

Create a separate thread for this problem and maybe someone with this router will be willing to share the default config with you.

UPDATE: Although, I do not see how you are gonna verify the config scripts without testing them on the router.

To be honest I don't know anymore if it is enabled by default. I would assume it is not for security reason.

You have the possbility to copy and paste your script over luci gui.
Either into rc.local (move or delete content after execution!) or into commandline directly (I remember that there was in the past the possibility in luci to enter commands via interface).


It's rc.local. And I know there was sth. like custom commands in LuCI but I cannot find on my build actually. So maybe it's not included in default builds.