thanks @eduperez, by reflash, do you mean ' Flash new firmware image' and upload the latest version again?
in which case, I've attempted to do this, I then performed a 'hard' reset by holding the reset button on my router for 10 seconds.
I've then configured my router again on a fresh install, wifi, PPPoE, etc. I've then created a backup. I then attempted to reset my router (to test) and it still reverts to default settings.
I attempted to restore the fresh backup, but it still reverts to default.
I'm seemingly missing something, and I've not experienced this issue before.
I have had the WRT32X for quite a while, but never needed the vendor specific 10sec reset.
Since Linksys also has a 10 second reset implemented,
I for myself am not exactly sure, what the WRT series vendor specific 10 second reset has as side effects, from what I think, this reset might be caught and executed by the vendor boot partition. Now this boot partition is not overwritten, when flashing OpenWRT to one of the 2 firmware partitions.
Generally this device has 2 firmware partitions and these get flashed alternating:
flashing WRT3200 from either a vendor partition or an OpenWRT partition will not overwrite the partition from where you have triggered the flash process, but the opposite partition. When this finishes successfully, a flag will be set one time in a config partition, the boot partition considers this flag, such that after the reset the boot loader will always boot into the new partition.
Now it could be that this vendor 10second reset (which is not implemented by OpenWRT) might reset this flag and it could be that you will then acccidently boot again into the old broken partition again.
You might want to try to use the power button sequence that triggers flipping the partition selector flag, such that the other partition gets booted. Steps are documented on the wrt3200 wiki page
Thanks @Pico Pico, this is super helpful. I attempted to install ' luci-mod-advanced-reboot' and did so on Luci, I then couldn't access the GUI interface, so guess I'll just stick to running the command via SSH.
This issue aside, I ran the relevant commands via SSH and was able to boot the opposite partition. It thankfully wasn't the default settings but contained changes I'd made previously. I'm wondering if now the router sees this as stable, so if I reboot it won't switch back from partition 1 to partition 2?
from the non-functioning partition, and post the link.
A script to boot the other partition from the CLI:
bootTaOther.sh
#!/bin/sh
#hacked from /lib/upgrade/linksys.sh
cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
target_firmware=""
if [ "$cur_boot_part" = "1" ]
then
target_firmware="kernel2"
fw_setenv boot_part 2
fw_setenv bootcmd "run altnandboot"
elif [ "$cur_boot_part" = "2" ]
then
target_firmware="kernel1"
fw_setenv boot_part 1
fw_setenv bootcmd "run nandboot"
fi
# re-enable recovery so we get back if the new firmware is broken
fw_setenv auto_recovery yes
echo "$target_firmware"
reboot
I note you've provided a script to boot to the other partition too?
I've taken a backup of my latest config, as everything is set up and worksing as I like. This partition boot issue is the last thing I need to address before I consider things stable. I'm pretty sure my wife will be glad of this once sorted.
Thanks, this will be one for tomorrow, when the house is empty. I'm extremely nervous to reboot the router for fear losing my settings again. But I appreciate its a necessary evil.
Have you tried taking a backup? Typically you can save your settings in a backup file (that will download to your computer). This is good practice in general, but if the settings don't persist across the reboot, you'll at least be able to restore them later*.
*warning -- restoring the settings does force a reboot of the router, which could basically lead to an annoying cycle of restoring/rebooting/losing settings.
That said, eventually you may experience a reboot or other situation (like a power outage), so you should try resolve this issue soon and just be prepared for the fact that the settings may not persist. Each time you test, though, only make a few minor changes so that you can test the reboot/save-settings without losing a lot of work.
I've been taking regular backups whilst I've been trying to get network stability.
*warning -- restoring the settings does force a reboot of the router, which could basically lead to an annoying cycle of restoring/rebooting/losing settings.
This is exactly the issue I've been facing, and the reason I came to the forum with the issue. I've a backup file with the 'as is' which has been stable for 48 hours.
I'm keen to get it resolved as like you say a power outage or a reboot will flip me onto the other partition. I know this would likely happen when I'm not home... because that's sods law!
If I was to perform a sysupgrade using the latets stable release, should that do the trick? I've noticed 'hostnames' is missing from network options in Luci on the snapshot build.
The image release version does not make difference.
The "latest stable" is mainly February 2021 code plus some patches, while you are now running the newest January 2022 code.
You current master snapshot contains already an important wifi fix that is missing from 21.02.1.
If I were you, I would sysupgrade to the newest snapshot to keep the wifi fix, but to have a different version than your current one, so that you can identify if you changed partitions. Apparently r18607-88204bfa82 is currently the downloadable snapshot.
Sounds strange.
Which exact place you mean?
I see quite normally the hostnames tab on the DHCP page in my router :
ahah, there it is. I could of sworn it was in the main dropdown from Network > Hostnames, maybe on a previous build, or maybe I've seen it on a tutorial somewhere.
Good thinking about running a different version. I think I'm running the non-snapshot build on the partition 2. But like you say worth while updating due to wifi fixes etc. Its currently a barebones setup due to me not initially understanding the parition situation. I just assumed it was losing my settings on reboot, but it was switching partition.