OpenWRT does not reset the failed boot counter

[cilynx]

Candyhouse routers have a failed boot counter that acts as a safety mechanism. After three failed boots, the bootloader automatically stops trying to boot the failing firmware image and switches to the other partition set -- the "last known good". OpenWRT is not aware of this couter and as such does not reset it on successful boot. Thus, if you reboot OpenWRT three times, you'll find that you're back to the Cisco stock firmware. The Candhouse OpenWRT images should reset the failed boot counter upon successful boot.

[cilynx]

This is going to be more difficult to implement than it was under Debian. The Cisco recovery binary expects libc.so.6 and ld-linux.so.3, neither of which are around on OpenWRT. I'm going to have to figure out how recovery actually interacts with s_env and duplicate the functionality.

[cilynx]

These will probably be useful:

u-boot-1.1.4-candyhouse_021_auto_recovery.patch u-boot-1.1.4-candyhouse_027_128MB_auto_recovery_NAND_WORKAROUND.patch u-boot-1.1.4-candyhouse_032_auto_recovery_page_write.patch

[fbradyirl]

Any workaround for this at present apart from "don't reboot" (might happen during power failure)?

[cilynx]

The best workaround is once it happens and you're back to stock, to force a few more "failed" reboots such that it switches back to OpenWRT. For the stock firmware to experience a "failed" reboot, you need to leave it powered on long enough for the kernel to start booting and increment the boot counter in the bootloader, but unplug it before the init script that resets the boot counter runs. It should be in the neighborhood of 5 seconds.

If you don't like guessing and hoping, you can always solder on a serial terminal and update the bootcmd parameter in uboot to boot the other partition.

http://www.wolfteck.com/projects/candyhouse/serial/ http://www.wolfteck.com/projects/candyhouse/uboot/

[fbradyirl]

Ah right I see. Nice. Thanks for the info. On Fri 8 May 2015 at 17:25 Randy C. Will notifications@github.com wrote:

The best "workaround" is once it happens and you're back to stock, to force a few more "failed" reboots such that it switches back to OpenWRT. For the stock firmware to experience a "failed" reboot, you need to leave it powered on long enough for the kernel to start booting and increment the boot counter in the bootloader, but unplug it before the init script that resets the boot counter runs. It should be in the neighborhood of 5 seconds.

If you don't like guessing and hoping, you can always solder on a serial terminal and update the bootcmd parameter in uboot to boot the other partition.

http://www.wolfteck.com/projects/candyhouse/serial/ http://www.wolfteck.com/projects/candyhouse/uboot/

— Reply to this email directly or view it on GitHub https://github.com/cilynx/Candyhouse-Linux/issues/1#issuecomment-100286485 .

[cilynx]

Another workaround would be to set uboot's 'auto_recovery' to 'no', but I'm really not a fan of that option as it greatly increases the chances of bricking the router to the point that you require a serial port to recover.

fw_setenv auto_recovery no

[fbradyirl]

I've actually since installed OpenWRT on my old Vodafone Huawei HG556a, and it works seriously well. I'm finding OpenVPN working blazingly fast compared to my E4200 running stock firmware. On Fri 15 May 2015 at 17:13 Randy C. Will notifications@github.com wrote:

Another workaround would be to set uboot's 'auto_recovery' to 'no', but I'm really not a fan of that option as it greatly increases the chances of bricking the router to the point that you require a serial port to recover.

— Reply to this email directly or view it on GitHub https://github.com/cilynx/Candyhouse-Linux/issues/1#issuecomment-102450626 .

[vxbinaca]

I'm getting the 3-reboot problem with the 4500 as well. Has anyone patched this yet?

[cilynx]

This isn't so much a simple patch as it is completely reverse engineering the safety counter and how to reset it. Unfortunately, it's not keeping a number in a text file or anything easy like that. It updates some values in flash space allocated to uboot. The time and effort required to reverse engineer the system probably isn't worth it when fw_setenv auto_recovery no works around the issue much more simply.

[vxbinaca]

Has it been worked around so I can compile and flash without having to worry about losing the firmware after 3 reboots?

[cilynx]

After you build and flash, run fw_setenv auto_recovery no on the router. That will disable the reboot counter and prevent the router from switching back to the other image no matter how many times you reboot.

Keep in mind you don't ever "lose the firmware". With the default settings, it just flips over to stock after 3 "failed" boots. See earlier in this thread for how to get back to your custom image after getting caught by the reboot counter.

[vxbinaca]

Okay, thanks. I thought that was something I had to compile in or set through serial. Thanks again.

[adrinux]

There was an openwrt commit to the mvebu target a couple of days ago, to implement boot counter reset: http://git.openwrt.org/?p=15.05/openwrt.git;a=commit;h=4300eee946b10f0d0277416808c836676f55adda

Pondering if this can be ported to the kirkwood target.

[adrinux]

It can be ported, I have it working, pull request to follow!

[adrinux]

I have a preliminary working bootcount reset for the ea4500 in my chaoscalmerfixes branch: https://github.com/adrinux/Candyhouse-Linux/tree/ChaosCalmerFixes

This has one minor issue in that once the build is flashed you still need to ssh in and set execute permissions on the recovery script:

chmod 755 /etc/init.d/linksys_recovery

I've no idea how OpenWRT sets the correct perms on scripts.

It should be possible to extend this to the other models, they just need their boardname listing in the right places. This is built on top of the existing pull request code I have.

[vxbinaca]

Why not check other scripts perms? ls -a should tell you.

[adrinux]

I'll need to double check, but afaik the script, on my hard drive, in the src, is set executable. The script is successfully integrated into the build and placed in /etc/init.d/. If you then flash that build and log in: At that point it's not set executable, hence the need to do it manually. During the build process the perms are changed.

I have a feeling the openwrt build system needs to be told somewhere what perms the script should have in its final location.

[adrinux]

I've fixed the issue with the script perms so the boot count reset now works out of the box. I've also extended it to the ea3500, but can't test that. So if https://github.com/cilynx/Candyhouse-Linux/pull/9 is pulled in this issue can probably be closed.

[frohro]

HiAdrian,

I'm having problems with the ea3500 going back to Linksys firmware after three boots. I tested part of your script, and it looks to get to the part where the reset of the boot counter happens (assuming the boot{} part does its thing. Are there other things I should check? Here is my test of your script: root@OpenWrt:/# cat ./test_linksys_recovery . /lib/functions.sh . /lib/kirkwood.sh

case $(kirkwood_board_name) in ea4500|ea3500)

make sure auto_recovery in uboot is always on

            AUTO_RECOVERY_ENA="`fw_printenv -n auto_recovery`"
            if [ "$AUTO_RECOVERY_ENA" != "yes" ] ; then
                    fw_setenv auto_recovery yes
            fi
            # reset the boot counter
    echo "reset firmware"
            mtd resetbc s_env
            ;;

esac root@OpenWrt:/# ./test_linksys_recovery reset firmware root@OpenWrt:/#

[frohro]

I should mention that I found that even using fw_setenv auto_recovery no doesn't stop the three reboot problem.

[adrinux]

I all I did was apply the changes in this commit (for newer linksys routers) to kirkwood http://git.openwrt.org/?p=15.05/openwrt.git;a=commit;h=4300eee946b10f0d0277416808c836676f55adda

It's possible the ea3500 is different enough that this wont work, or wont work without changes. Sorry I can't be of more help.