I am working with a few Linksys WRT1200AC.  They have a few shell scripts, rc.local calls to the scripts and cron jobs, which cause the system to reboot every 15 minutes in an internet connection is not seen. While testing without internet ! saw the routers locked up occasionally, but looking in the discussions I saw an issue similar to this: https://dev.openwrt.org/ticket/17839 .  This lockup issue was overcome by adding a 15 second wait in scripts called by rc.local as mentioned in the 3 comment. (might this need to be fixed in code like the other router?)

I installed the base Openwrt "Stable" install, then reverted back to the factory router software (from Linksys) when I noticed issues and saw that the build was only for V1 (I have v2 routers). This was done through the OpenWrt interface) Then I installed kaloz Repository Mildly Customized Chaos Calmer [CC] Build as it lists the V2 sofware (through the web interface).  I set up the routers by extracting a tar.gz backup on the command line, and then changing the WiFi name though the interface. This all seems to work well, but while testing 4 routers without internet (they rebooted every 15 minutes from the cron job) I noted that after a day one of them has reverted to the Linksys Software, but with some of the settings I had set up on the OpenWRT software, but with the old WiFi name from the tar.gz ball.

How is this even possible?  I assume the system is keeping the previous install of the firmware somewhere and is triggering a restore.  Is there a way to disable this?

P.S. I have seen something similar with a Linksys Archer C-7 router as well.

(Last edited by mschneider1 on 19 May 2017, 15:32)

According to https://wiki.openwrt.org/toh/linksys/wrt_ac_series the router maintains two separate firmware partitions. When you boot one of them and perform a flash, it flashes the other image, and then you can boot to that. This is a fail-safe feature, allowing you to maintain a bootable firmware image in case a flash goes bad.

Don't know how to disable it.

you may need to specify the partition to boot to in the reboot script to keep that from happening. I don't have the command in front of me, but if you can't find it, let me know.

Another solution would be to run the same software with same configurations on both partitions.

(Last edited by davidc502 on 19 May 2017, 20:47)

"fw_setenv auto_recovery=no"  to disable the auto switching if booting fails 3 times, though don't think that would help with your issue. Sounds more like something is off with your use of rc.local / cron jobs.

Doubt it is anything with my rc.local.  It conditionally extracts an OpenWRT tar.gz backup if a file exists (which right now is impossible, as the file has never been put on these routers) plus I don't see how extracting a OpenWRT backup file can cause a system to revert to Linksys firmware.

(Last edited by mschneider1 on 22 May 2017, 16:14)

The OEM firmware can't use anything related to OpenWrt (beside storing configuration in a different place I doubt it has even support for the filesystem used by OpenWrt). So something is very odd with your observation of using some configuration from OpenWrt, could you elaborate a little more? Also why would you reboot if there is no internet for 15 minutes, what is the purpose? Also you have 4 routers, I assume all being setup the same way, is it always the same one having this issue?

So far all I can say is booting fails really early (before resetting the boot counter) and after 3 failed attempts the bootloader switches to the alternative image. The switching you can prevent with the command I posted before but that wont solve your issue, however might help with debugging. Can you post a boot log obtained via serial connection?

Rebooting every 15 minutes if there is no internet to have the router reset its settings.  I am doing this because sometimes I have had issues because some of these routers are on questionable networks, and rebooting after 15 minutes if the WAN connection fails has saved me a lot of calls.  The problem corrects itself, and the router starts working again.

Routers were all set up the same. Installed the same img file, run the same scripts to install packages, and all copy over tar.gz backup file made from the master router then installed it. I just went in and changed the WIfi to have 1, 2, 3 or 4 and the end of the wifi name to tell which ones are up without having to log into each.

I then unplug the WAN jack and let the router stay unconnected from the network. After a day the first router went reverted to  linksys firmware.  The local password however was not the default password, but the password that was configured under Openwert.  Doesn't seem to be any one router, and it seems random when they revert. I have never had 2 revert at once, but I have had it 3-4 times on different routers.  Right now 2 are out after the weekend.

All routers are on the same power switch, all are running the same config, only difference is the 1,2,3, and 4 on the Wifi name.  (2.4, 5 ghz is turned off)

Ah, rebooting as sledge hammer approach, sure why not.

As for the password I don't have an explanation at all. Really shouldn't be possible.

One possibility for not booting is some filesystem corruption. Maybe kill processes which write to nand and issue an fsync before issuing the reboot might help. Either way I'd disable auto_recovery so the unit will end up with an infinite boot loop. Once you notice one unit went south connect an usb2ttl cable to get a boot log. There might be some decisive hints.

Also if you never have an internet connection the system time might be rather off as there is no usable RTC. So how you determine the 15 minutes might play a role as well.

I don't think the bug you linked to is related, but then I don't yet understand what is going on either.

auto_recovery is disabled I will see if that fixes the issue.

The rebooting is from a cron job that runs a shell script on the 15s (*/15 * * * * /folder//RebootAsNeeded.sh). It uses wget to see if a web site can be reached.  If it cannot see the website, it then triggers a reboot.  I chose a reboot because I didn't know if the routers WAN port had locked up, if the gateway was having issues, if the DHCP server had rebooted and given out the IP address to another device, or if the person had set up another device with the same static IP (which was the case).   I left the reboot in the routers as a fall back fail safe for a world of problems that I knew should work.  99% of the time the routers never reboot. If they do, at least I have a chance to remotely access them and determine what is going on without having someone having to be there to physically turn the router off and back on. Sort of a hammer, but this issue is a bit of a nail, so it works.

The bug I linked to is another issue on these routers.  If I don't put a 15 seconds delay at the top the shell script called in my rc.local, the routers lock up totally on some reboots. no Wifi, no LAN, no WAN.. Exactly like what was happening in the the other router.  I am just leaving the 15 second delay in my script as it fixes the issue (just like it did on the other thread), and I don't have to wait for another stable build.  I just mentioned it as it might need to be fixed for this router.

And your RebootAsNeeded.sh does the "sleep 70 && touch /etc/banner" game? As I said upon boot your time is a mess and without internet no synchronization happens. So you have to be really careful if you reboot from a cron job. Cron has a resolution of 1 minute so 15 seconds won't help, but as I understand you the 15 seconds are for the rc.local tar extraction.

Disabling the auto_recovery seems to have fixed the issue.  4 routers stayed unplugged over the extended weekend, and not one of them had issues.  I am not sure when you would ever want to use the auto_recovery anytime except after the first boot fails after an update.  Seems to be more a security risk than anything. If I can somehow get the device to reboot a few times in a row, I can get it to revert its firmware.

There are advantages and disadvantages to auto_recovery. Beware of sysupgrade probably re-enabling auto_recovery.

Understood,  I will keep that in mind, and thanks.