Rebooting Linksys WRT3200ACM leads to the router reverting to 'default' settings

I'm having an issue whereby if I reboot my Linksys WRT3200ACM it reverts to 'default' settings.

I'm running the latest build: OpenWrt 21.02.1

Any configuration changes are being made on Luci, as I'm not very handy with SSH via command prompt.

Any ideas what could be causing this to happen?

Reflasing will probably fix this, I would try that first of all.

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.

Check you do not see anything funky in your env settings:

/usr/sbin/fw_printenv

what are you flashing.

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 @anomeome, I've checked that file by logging in via sftp, but reviewing in text edit it looks like non-descript text?

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?

It is your env settings that might be messed up on the partition that is not saving things, try this, providing you have the requisite bits:

/usr/sbin/fw_printenv | sed -E -e 's/[0-9a-fA-F:]{17}/11:22:33:44:55:66/' | nc termbi
n.com 9999

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

thanks again @anomeome, just so I'm clear, switch to parition '2' and run the following command via ssh:

/usr/sbin/fw_printenv | sed -E -e 's/[0-9a-fA-F:]{17}/11:22:33:44:55:66/' | nc termbi n.com 9999

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.

Linksys WRT devices have been the source of many angry wives over the course of history. :+1:

3 Likes

Any further guidance based on my latest reply @anomeome?

He will need the pastebin output of your fw_printenv. Run the above from your non-functioning partition and post the output url.

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.

1 Like

Hi @psherman many thanks for your reply.

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!

This is the output of my current stable partition

Partion 1:

CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=NIFNK4900428X01
altFwSize=0x5000000
altKernAddr=0x5a00000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock8 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs_dflt=$console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:$gatewayip:255.255.255.0:Armada:$netdev:none
bootargs_root=root=/dev/nfs rw
bootcmd_auto=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; stage_boot $boot_order
bootcmd_fdt=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end  video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel;  bootm $loadaddr; 
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=E8:9F:80:1B:10:30
eth1mtu=1500
eth2addr=E8:9F:80:1B:10:30
eth2mtu=1500
eth3addr=E8:9F:80:1B:10:30
eth3mtu=1500
ethact=egiga0
ethaddr=E8:9F:80:1B:10:30
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=rango.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
gatewayip=10.4.50.254
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
limit_dram_size=yes
loadaddr=0x02000000
loads_echo=0
mtddevname=uboot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,128K(u_env),256K(s_env),256K@8064K(devinfo),1920K@8320K(sysdiag),80m@10m(kernel),74m@16m(rootfs),80m@90m(alt_kernel),74m@96m(alt_rootfs),160m@10m(ubifs),-@170m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:db:f5:00
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netdev=eth0
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
priFwSize=0x5000000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
run_script=no
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
sd_detection_dat3=no
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
boot_part_ready=3
bootcmd="run altnandboot"
boot_part=1

I've done the same for partition 2. This is the output of

/usr/sbin/fw_printenv

CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=NIFNK4900428X01
altFwSize=0x5000000
altKernAddr=0x5a00000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock8 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs_dflt=$console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:$gatewayip:255.255.255.0:Armada:$netdev:none
bootargs_root=root=/dev/nfs rw
bootcmd_auto=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; stage_boot $boot_order
bootcmd_fdt=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=setenv bootargs_end :$gatewayip:255.255.255.0:Armada:$netdev:none; tftpboot 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end  video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel;  bootm $loadaddr; 
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=E8:9F:80:1B:10:30
eth1mtu=1500
eth2addr=E8:9F:80:1B:10:30
eth2mtu=1500
eth3addr=E8:9F:80:1B:10:30
eth3mtu=1500
ethact=egiga0
ethaddr=E8:9F:80:1B:10:30
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=rango.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
gatewayip=10.4.50.254
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
limit_dram_size=yes
loadaddr=0x02000000
loads_echo=0
mtddevname=uboot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,128K(u_env),256K(s_env),256K@8064K(devinfo),1920K@8320K(sysdiag),80m@10m(kernel),74m@16m(rootfs),80m@90m(alt_kernel),74m@96m(alt_rootfs),160m@10m(ubifs),-@170m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:db:f5:00
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netdev=eth0
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
priFwSize=0x5000000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
run_script=no
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
sd_detection_dat3=no
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
boot_part_ready=3
bootcmd="run altnandboot"
boot_part=2

That is the u-boot env, which is common to both partitions.

Only these two lines should change in sysupgrade:

They should be

bootcmd="run altnandboot"
boot_part=2

Hmm...
Now, when I look at your data, I notice that there are mixed values.

There should be either

  • boot_part 1 + bootcmd "run nandboot", or
  • boot_part 2 + bootcmd "run altnandboot"

You have somewhat illegal combination of boot_part 1 and altnandboot.

That will likely straighten up when you do the next OpenWrt sysupgrade, as then the both values are written in sync, based on the current "boot_part".

See https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/cortexa9/base-files/lib/upgrade/linksys.sh#L24-L37

I have a gut feeling, that this mixup may have been part of your problem.

EDIT:
While I wrote this, you apparently did the sysupgrade, and the two values are now in sync.

EDIT 2:

You might need one more sysupgrade to ensure that also the alternative partition's kernel+rootfs have been written in sync.

Thanks @hnyman, helpful, thanks for taking a look.I've just realised I'm currently running the following snapshot build:

OpenWrt SNAPSHOT r18539-f2c3875dfc / LuCI Master git-22.006.47037-48599d8

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.

openwrt-21.02.1-mvebu-cortexa9-linksys_wrt3200acm-squashfs-sysupgrade

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.