Linksys Wrt32X issue

Hello, I hope someone can help me regarding openwrt on a Linksys WRT32X router. I received this and absolutely can't get it off the part. No matter what I always try OpenWRT. Could someone possibly help me?

My guess is that the previous owner somehow pushed openwrt to partition 1.
I tested it via Tftp / Putty and various instructions but unfortunately without success.

Sorry for the bad english!

That is so vague, that please start the explanation again...

What is the problem?
What do you want to actually do?
(Which exact OpenWrt version your router is running?)

Hello, so I bought a Linksys Wrt32X. The previous owner kinda put openwrt on it. It also starts when you turn on the router, but I would like to have the entire router on factory firmware (original) first.

Now I've tried to bottle the router again, but for inexplicable reasons it doesn't work at all.

First I pinged the router to 192.168.1.1 which also worked.

Then I tried to get the router back to the original as described by Linksys, but it doesn't work.

I also tried to get to another partition, which didn't work (I have the feeling that Openvpn was installed on partition 1 and there is nothing on partition 2.

No matter what I try, whether I try to install via Putty or TFTP as recommended by Linksys, nothing works and it always starts openwrt.

Even after these instructions only with Wrt32X no success.

I had read that I needed a serial USB cable and had to open the router, but I can't confirm whether that's the only way.

linksys wrt32x has 2 partitions. Do 3-on 3-off for 10 seconds each and you can manually switch to the other partition.

The advice I'd have given myself when I first received mine is to install openwrt at least 2x (1 per partition) and then you wont have this problem.

opkg update && opkg install luci-app-advanced-reboot
will allow you to see your partitions.

1 Like

Personal experience but you have to use the -f or force option if you want to install the original linksys firmware. it will fail otherwise.

The Linksys advice that you linked above, only works if OpenWrt has been flashed to one partition and the other partition still has the Linksys OEM firmware. The advice only tells you how to switch booting to the other partition. If you have OpenWrt on both partitions (like usually...), the procedure just toggles the booting to happen from the second partition.

I assume that with "factory" you refer to the Linksys OEM firmware.
(Note that in OpenWrt language, the "factory" is mage usually means the initial install image of OpenWrt that can be flashed from a router currently running Linksys OEM firmware, and the "sysupgrade" image is the one used when upgrading a router currently running OpenWrt router.)

There is nothing magical about "having the router on OEM factory firmware" first. Both Linksys OEM firmware and the OpenWrt firmwares write exactly the same flash areas, so if you intend to stay with OpenWrt, there is no benefit from going back to Linksys. But if you aim to drop OpenWrt totally and just have the Linksys OEM firmware there, then it is another story.

Some advice for going back to Linksys from SSH console:

You can also do the same from LuCI GUI:

  • download the proper Linksys OEM firmware from their site to your PC.
  • when you try to sysupgrade in LuCI with that image, the mage check fails. Override that with selecting "force" and also unselect the "keep settings".
1 Like

Thanks for the tip from "kufkis"
I also did it exactly as you wrote.
After that I was shown under System - Advanced Reboot, with 2 partitions.
Partion 1 - Current - openwrt 21.02.2 and Partion 2 - alternative - linksys and a button with reboot to alternative firmware.
If I press the button, the router restarts and after a few seconds it has fully booted up again, but the "Internet" indicator lights up yellow and I have neither access to the Internet nor to the router (should be blue). A reset does not bring success either, it always comes back to this point.

So I have to switch off then on and do it 3 times so that I have access and internet again. But then I'm back on openwrt

@hnyman I also tried your two links with this firmware from Linksys homepage:

unfortunately also without success
I also did the same thing with Luci, which was also unsuccessful

Can it possibly be that the 2nd partition is damaged or empty? or the predecessor did something wrong when installing?

Hey, this may sound trivial, but when you reboot to the alternative firmware, you may also need to reboot the other equipment. They may have different local keys that identify them on the LAN. your local devices could be treating your alternative boot settings as an intruder since the router was just using different settings.

Unfortunately, restarting all other devices does not bring the desired success. The internet control lamp doesn't really have anything to do with the other devices either. It only shows that it is connected to the internet.

Unfortunately, access to the Linksys is also not possible.
Do you have any other idea???
Can it be that the alternative firmware is defective?

Not really, at least the firmware itself, as that no role in flashing a new one.

The flashing routine (both by OpenWrt and by Linksys) always overwrites the other partition and keeps the current one as fallback. So the contents of the other partition do not matter much.

You should install that luci-app-advanced-reboot that kufkis mentioned and

  • see what it shows as the partition contents. I guess that both partitions may contain OpenWrt at this point. Alternatively, the other one may now contain Linksys but doesnät boot.
  • test if you can toggle booting to happens from the other partition.

I have already installed and booted directly from there, unfortunately without the desired success, as already mentioned above





So no matter what I do, I can't get to Linksys

That sysupgrade from SSH looks normal, upto the moment when network connectivity is broken (normal).

One possibility is that there is something wrong with the boot commands in u-boot.

If you run the command fw_printenv from SSH console, what u-boot variables you see?
The boot commands in use should be visible.

Please copy them from your terminal here as text, instead of taking a photo.

root@OpenWrt:~# fw_printenv
CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=NJ2PH3100766X01
altFwSize=0x7B00000
altKernAddr=0x8400000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock8;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootz $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot-part=1
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part=1
boot_part_ready=3
boot_▒part=2
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=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run nandboot
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=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=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=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=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=60:38:E0:C3:16:98
eth1mtu=1500
eth2addr=60:38:E0:C3:16:98
eth2mtu=1500
eth3addr=60:38:E0:C3:16:98
eth3mtu=1500
ethact=egiga0
ethaddr=60:38:E0:C3:16:98
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
fileaddr=1000000
filesize=21E0000
firmwareName=venom.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
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),123m@9m(firmware1),123m@132m(firmware2)
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;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootz $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
priFwSize=0x7B00000
priKernAddr=0x0900000
priKernSize=0x0600000
print=boot_part
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
root@OpenWrt:~#

some wonky char in your env?

script
#!/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

Edit: therre appears to be a character in your env thaat does not belong and is probably stopping you device from switching partitions correctly.

unfortunately I don't know what you mean

I spotted the same anomaly that @anomeome noticed.

Looks like somebody (the previous owner?) has manually tried to edit the boot_part variable and now there is both erroneous boot-part and boot_#part with an invalid char in variable.

Just a guess, but that might be the reason for being unable to toggle booting.

1 Like

You should get rid of boot-part and boot_▒part

Based on fw_setnv manuals, that should be accomplished with

fw_setenv boot-part
fw_setenv boot_▒part

See https://www.unix.com/man-page/debian/8/fw_setenv/ or http://manpages.ubuntu.com/manpages/bionic/man8/fw_setenv.8.html

You might need to copy paste that variable name with ▒

EDIT:
See that script that is in @anomeome's message hidden behind that triangle.
The toggled boot variables are

   fw_setenv boot_part 1
   fw_setenv bootcmd "run nandboot"

or

    fw_setenv boot_part 2
    fw_setenv bootcmd "run altnandboot"

Your extra boot-part and boot_▒part may cause confusion in the u-boot if they are parsed. E.g. even if you toggle boot_cmd to 2 in the sysupgrade process, the "wrong" variable boot-cmd stays 1 and if that is parsed first with "case-insensitive" _ or - , the boot might stay on 1

1 Like

Unfortunately I do not understand how to get to the script. Do I have to have Linux there? If so, I'll have to come up with something else.

There is z copy icon in the corner of the window when you open the script pulldown, ssh into to your device, copy into file and run

cd /tmp
vi bootTaOther
chmod +x bootTaOther
./bootTaOther

or just fix up your env as per what you see in the script as indicated above by @hnyman post. There is also a uboot command to reset your env, IIRC resetenv, not sure if that is available at the CLI in OpenWrt though.