Interesting info on the rango reboot.

Just have a try to revert commit by Felix Fietkau 8 days ago, with latest trunk build, so far so good.
I think something about shadowsocks-libev getting wrong with what FF committed, not 100% sure, but thats what I can tell so far.

git pull
git revert 2dc485250d
Revert "mac80211: tweak TSQ settings"

To whom it may concern, Felix reverted the commit and soon afterwards fixed a bug and recommitted.

Sorry for not understanding but what problem does this fix?  I'm having difficulty translating commits to fixes.

(Last edited by kirkgbr on 1 Dec 2017, 15:49)

Follow thread from link in my post 4 back.

Ah, Rango only.  Thanks.

We had a power outage this morning and my 1900acsV1 rebooted into the stock firmware.  Now I can't get it to revert back to the other partition.... I think anyway.  The sysinfo.cgi doesn't report a value for boot_part and it has a boot line of cat /proc/cmdline: console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m@9m(devinfo),40m@10m(kernel),34m@16m(rootfs),40m@50m(alt_kernel),34m@56m(alt_rootfs),80m@10m(ubifs),-@90m(syscfg)
   I've had issues in the past with the partitions where the system would only flash from one partition and onto the other.  Tried flashing with stock firmware, the three times on/off to switch partitions and restore previous firmware button in the config.    Nothing worked.  I'm stuck with a device on OEM firmware that won't flash.  Any suggestions?

depending on which stock firmware you are on linksys added a revert to previous firmware (or something similar) in diags or troubleshooting somewhere.

I know its there just don't remember exactly where.

Thanks for the reply.

Troubleshooting -> Diagnostics.  I gave that button a shot.  Nothing seems to get it to boot up in the other partition or flash an open firmware.   This may boil down to starting from scratch using a serial connection.  It's hard to justify that when the device isn't bricked.

Well its normal to keep getting the same firmware to come up if the other is hosed somehow because it auto-reboots to that one if it can't boot the selected one.  If something is hosed in your overlay flashing lede/openwrt is still going to fail to boot.

After choosing revert, try repeatedly pressing the reset button again and again while it is trying to boot to see if you can at least get failsafe mode up. Just keep press and release it until it is booted.  If that boots you can then use the firstboot command to reset /overlay.  Hope you did back up your config

https://wiki.openwrt.org/doc/howto/generic.failsafe

(Last edited by WWTK on 25 Dec 2017, 13:45)

I flashed with lede and the packet never came though to my tcpdump session.  Then I flashed a prior version of OEM (1.0.0.169041) and was greeted by the (1.0.3.182461) version that was on the other partition.  It's like the system has marked the other partition as corrupt or something.  Yes, I took a backup a month ago . 

I don't remember these in http://192.168.1.1/sysinfo.cgi being blank before:

-----U-Boot Data-----
fw_printenv bootdelay: 

fw_printenv mtdparts: 

fw_printenv bootcmd: 

fw_printenv boot_part: 

fw_printenv auto_recovery: 

fw_printenv mtdparts_version: 

All fw_printenv:

(Last edited by lyz on 25 Dec 2017, 14:26)

did you try failsafe mode?  it will boot even if /overlay is broken. 

There is nothing you can do about the uboot vars without a serial cable or ssh access, so they are sort of moot at this point.  you might be able to fix them from failsafe mode though.

from my 1900acs

-----U-Boot Data-----
fw_printenv bootdelay: bootdelay=3

fw_printenv mtdparts: mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m@9m(devinfo),40m@10m(kernel),34m@16m(rootfs),40m@50m(alt_kernel),34m@56m(alt_rootfs),80m@10m(ubifs),-@90m(syscfg)

fw_printenv bootcmd: bootcmd=run altnandboot

fw_printenv boot_part: boot_part=2

fw_printenv auto_recovery: auto_recovery=yes

fw_printenv mtdparts_version: 

(Last edited by WWTK on 25 Dec 2017, 15:58)

The packet that indicated fail safe was active never came through.  I checked the lights and it doesn't follow the rapid reboot sequence it had when I had prior issues.  It looks like it is just refusing to boot to the other partition.  I'm not sure how to get to failsafe mode in this case.  Thanks for posing your uboot values.  For some reason, my router has those values as all blank.  It's probably time to buy that serial cable...

(Last edited by lyz on 25 Dec 2017, 17:48)

the other possibility is you now have the same linksys oem fw on both partitions making it look like it isn't switching.  I know they did stuff on other routers that prevent openwrt/lede from loading though I've not heard that with the 1900acs.

You might try flashing an old version of the firmware like from when it was released kind of era.

EDIT:

or even try dd-wrt

(Last edited by WWTK on 25 Dec 2017, 18:05)

FYI: Announcing the OpenWrt/LEDE merge

Hi Villeneuve Can you give me more info on the build for the wrt3200acm in your sig pleas. Who is building it? I see that's it is on k4.14.

I put up a 4.14 build to assist with testing the change on new rango units to the Winbond flash device.

Hi Villeneuve thanks for the build. Could any one that has a wrt3200acm pleas post me the /etc/config/wireless file.
I don't know why but the wifi settings are mest up on k4.14

https://github.com/nitroshift/wrt3200ac … bootloader

nitroshift

Hi nitroshift do I need that? Am I stuck on this build?

@tapper see last post:

https://forum.lede-project.org/t/wrt190 … lotadmirer

Or, in short... on 4:14 the sytanx for Rango is

soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0
soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0

@Tapper

That's the bootloader recovery files and instructions, not a firmware, and I posted the info for anyone interested.

nitroshift

For anyone having last-batch Rango units with winbond flash: https://git.openwrt.org/?p=openwrt/stag … ;a=summary

Just got a brand new WRT3200ACM and it's bricking with David's latest build.  Is this possibly due to the Winbond flash issue?

In all likelihood if the  DoM is later than ~Dec'17, See thread.