I flushed my EA6900 with build date 12/22/14. Everything seems working except when I reboot, all the usb setting were gone, left on the default: usb not enabled.
This is must be a bug, I searched and does not seems its listed anywhere.
Is there a fix?
Did you check your nvram size?
If it's over 32K, than that's your problem.
I flushed my EA6900 with build date 12/22/14. Everything seems working except when I reboot, all the usb setting were gone, left on the default: usb not enabled.
This is must be a bug, I searched and does not seems its listed anywhere.
Is there a fix?
Did you check your nvram size?
If it's over 32K, than that's your problem.
Thanks for the speed replay.
I just checked. Here is the result:
size: 35078 bytes (30458 left)
What should I do?
I put this in my start up script, that fixed the problem:
Code:
for line in `nvram show | grep =$ `; do var=${line%*=}; nvram unset $var; done
Posted: Mon Feb 16, 2015 20:39 Post subject: Cannot upgrade from build 25974
I have two EA6900, and I'm trying to get them on the same release of DD-WRT. One is running 25974 and the other is running 26138. The one running 25974 will accept the upgrade, but afterwards it is still running 25974. It accepts the file and reboots, but then starts up with 25974. I've tried flashing it back to stock firmware, flashing to a dozen other releases of DD-WRT, but it just seems like it won't change. No matter what I give it (stock or otherwise) it is still running 25974 when it boots. I've tried TFTP as well but I can't seem to get the timing right to put the file on it. Any ideas?
skfurr2
I had exactly the same problem. The most reliable way to upgrade is from telnet (ssh shouldn't be activated on this router, unless you don't have 32k bug):
Code:
cd /tmp
wget http://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2015/02-04-2015-r26138/linksys-ea6900/linksys-ea6900-webflash.bin
mtd write linksys-ea6900-webflash.bin
erase nvram
reboot
Be patient after command "mtd write ...", because it will take a while. It is also essential not to forget "erase nvram" - without it even this method of upgrading failed in my case.
can I have a quick and easy way to flash my ea6900 with dd-wrt please? It really deserve putting on the 1st post of the thread. Thanks a lot!
блиндирани вративративходни врати
Last edited by ocina on Wed Feb 25, 2015 14:53; edited 1 time in total
Wow, that was great! I was able to flash it with no problems using the code you gave.
I did have to add one term to the mtd line:
Glad it helped you.
ocina wrote:
can I have a quick and easy way to flash my ea6900 with dd-wrt please?
It should be as easy as just making firmware upgrade from the Web GUI - no 30/30/30 reset and other stuff. There are however two things you should know:
1. You should first flash an early version of dd-wrt, and then make an upgrade to a modern one.
2. For safety reasons, this router has two spaces to keep firmware image. Therefore if you want to stick to a particular version, you should flash it twice, i.e. flash a certain version, and then flash it again as if you were doing an upgrade.
On the other EA6900 I had issues getting the firmware written twice. Everytime I did the second flash it rebooted to the stock Linksys firmware again! It seemed like perhaps something wasn't written right, because the first time I flashed it to DD-WRT it would boot to DD-WRT, but on subsequent reboots (whether it was a simple reboot, power cycle or another flash) it would boot back to the Linksys firmware. Very odd!
What's disconcerting is that I don't know what finally fixed it, but I went through about 20 flashes until it finally stopped booting back to the stock firmware.
I think your strategy is best: flash to DD-WRT 23194 (since it appears to be the latest version that is small enough to flash from the stock firmware.)
Then using telnet write the 26138 version, clear NVRAM, reboot, and write it a second time via telnet.
Are issues like this (not booting to DD-WRT and it reverting to stock firmware, not being able to flash to the later [larger .bin] firmware levels from stock, etc.) common? Or am I just unlucky?
No, Stephen, its not about luck
I have the EA6700 (-CE model), and I have been experiencing the same issues you described :
- second DD-WRT flash reverts the router back to stock firmware
- rebooting or powering off the router reverts it back to stock firmware
The difference my side is that I've been struggling to get a Kong's build
(http://desipro.de/ddwrt/K3-AC-Arm/dd-wrt.v24-K3_AC_ARM_STD.bin) flashed directly and have
never used the "eaxxx-weblash.bin" versions so far.
But as people have suggested above - "proper" way does seem to be flashing the earliest/first available
eaxxx-webflash.bin-build for your router via linksys web-gui, then reboot, then telnet to dd-wrt and flash
latest available eaxxx-webflash.bin-build twice.
I'm still not sure, which "flash two times" method is the right one, though :
- when you have first flashed from linksys web-gui and dd-wrt boots up,
you telenet to the router and use mtd + erase nvram two times, one after
another
- when you have first flashed from linksys web-gui and dd-wrt boots up,
you telnet to the router and use mtd + erase nvram, and reboot
- when the router has finished booting up, you telnet to it and again
use mtd + erase nvram
Would soneone shed some light on this topic, please ?
Thanks !
Posted: Thu Feb 26, 2015 5:44 Post subject: Works but WiFi lost after reboots
I installed DDWRT as described by depswa. Thanks for that.
However, I noticed that after some configurations, WiFi signal is lost across reboots. That doesn't happen when I boot using a previous backup, but after more reboots, it fails again.
Are we affected by the 32k nvram bug? How to handle it?
Are we affected by the 32k nvram bug? How to handle it?
Simple answer, yes looks like.
You can check it under "Status" - "Router" - "NVRAM"
e.g. mine is...
"NVRAM 39.60 KB / 64 KB"
...but I use the Asus CFE.
Solution:
Flash your backup or 30/30/30 and take care about the nvram usage..
e.g Keep SSH disabled, it uses a lot of space[/quote]
Posted: Fri Feb 27, 2015 21:04 Post subject: Experience with bad firmware flash and recovery.
My first (misguided) attempt at flashing a custom firmware to my EA6900 (v1.1) failed miserably. I used the stock GUI to upload an OpenWRT build... I assume the actual writing went okay, but after the device attempted to reboot, the LED would remain flashing indefinitely (yes, I did wait longer than 10 minutes). It would respond to ping, but nothing else, and I was unable to get TFTP to work, even with many attempts and 30/30/30 resets. Eventually, I left the router powered on (with the LED still blinking and went to bed.
In the morning, I decided to have a look inside in preparation for a serial recovery, so I powered down the router, cracked it open, and began inspecting the PCB. On a whim, I powered it up again, and this time, after a couple minutes of blinking, the LED went solid... I checked the web interface, and the stock firmware was back!
This story is still ongoing, and continues with a three-step DD-WRT flash (small, new, new) and lots of bumping into the 32k bug, but I'll stop here for now because I want to make an observation:
I wonder if the Linksys CFE sets a watchdog timer (of more a few minutes at least) which, if expired without being cleared by a functioning firmware, is detected on next boot and causes the CFE to flip the firmware pointer and attempt recovery. This might explain a lot of cases where the previous firmware comes back for seemingly random reasons. In fact, if the DD-WRT firmware doesn't include code to clear this timer, I bet that *every* DD-WRT boot lasting longer than whatever the timer length is (10 minutes? a couple hours?) causes the CFE to flip the flash - if you have double-flashed DD-WRT, this of course has no practical implication, but if you haven't, it would flip every time you ran one version for more than a certain amount of time and then rebooted.
An alternate theory is that I somehow managed the exact right reset button timing on the last boot before I went to bed to cause the CFE to flip (is this even a known behavior?), and the stock firmware took effect on next boot... but somehow this seems a little less likely.
Does anyone else have any experience to support / refute this?
Posted: Fri Feb 27, 2015 23:12 Post subject: Re: Experience with bad firmware flash and recovery.
p120ph37 wrote:
My first (misguided) attempt at flashing a custom firmware to my EA6900 (v1.1) failed miserably. I used the stock GUI to upload an OpenWRT build... I assume the actual writing went okay, but after the device attempted to reboot, the LED would remain flashing indefinitely (yes, I did wait longer than 10 minutes). It would respond to ping, but nothing else, and I was unable to get TFTP to work, even with many attempts and 30/30/30 resets. Eventually, I left the router powered on (with the LED still blinking and went to bed.
In the morning, I decided to have a look inside in preparation for a serial recovery, so I powered down the router, cracked it open, and began inspecting the PCB. On a whim, I powered it up again, and this time, after a couple minutes of blinking, the LED went solid... I checked the web interface, and the stock firmware was back!
This story is still ongoing, and continues with a three-step DD-WRT flash (small, new, new) and lots of bumping into the 32k bug, but I'll stop here for now because I want to make an observation:
I wonder if the Linksys CFE sets a watchdog timer (of more a few minutes at least) which, if expired without being cleared by a functioning firmware, is detected on next boot and causes the CFE to flip the firmware pointer and attempt recovery. This might explain a lot of cases where the previous firmware comes back for seemingly random reasons. In fact, if the DD-WRT firmware doesn't include code to clear this timer, I bet that *every* DD-WRT boot lasting longer than whatever the timer length is (10 minutes? a couple hours?) causes the CFE to flip the flash - if you have double-flashed DD-WRT, this of course has no practical implication, but if you haven't, it would flip every time you ran one version for more than a certain amount of time and then rebooted.
An alternate theory is that I somehow managed the exact right reset button timing on the last boot before I went to bed to cause the CFE to flip (is this even a known behavior?), and the stock firmware took effect on next boot... but somehow this seems a little less likely.
Does anyone else have any experience to support / refute this?
EA series routers have primary kernel, rootfs and the alternate or secondary kernel and rootfs. This is used for fallback incase there is a problem booting from one of the partition. So after few failed boot attempts, the alternate partitions are used which would have a different kernel and rootfs (probably Stock in your case). And this is how the "Roll back to previous firmware" works in the Stock GUI. It essentially boots from the a different partition upon reboot.
Posted: Mon Mar 02, 2015 21:53 Post subject: Re: Experience with bad firmware flash and recovery.
Dhiru wrote:
EA series routers have primary kernel, rootfs and the alternate or secondary kernel and rootfs. This is used for fallback incase there is a problem booting from one of the partition. So after few failed boot attempts, the alternate partitions are used which would have a different kernel and rootfs (probably Stock in your case). And this is how the "Roll back to previous firmware" works in the Stock GUI. It essentially boots from the a different partition upon reboot.
Check the output of "cat /proc/mtd".
Yeah, I'm aware of the two sets of images - what I was trying to figure out was what exactly ends up triggering the switch. I read the Broadcom CFE source, and this is my interpretation of how it works:
bootpartition contains the currently active image id from which the CFE will attempt to boot.
partialboots is incremented by 1 by the CFE every boot.
The firmware is expected to reset partialboots to 0 if it loads successfully.
If the CFE ever encounters a case where partialboots > maxpartialboots, it will flip the bootpartition value and set partialboots back to 1.
maxpartialboots is set to 3 in the factory nvram settings.
In my specific case, I think it may have flipped multiple times throughout the evening without me noticing while I was trying to hit the TFTP window, and it just happened that the final boot before I went to bed was a partialboot #4 of my bad flash, so the next time I powered it up, it went back to the other (stock) firmware.
There is also a watchdog timer, which in some cases seems to cause reboot loops, but I haven't deciphered exactly when that can happen yet.
I did try to figure out what the timing would need to be in order to power down the router between the CFE partialboots-increment and the firmware partialboots-clear in order to intentionally induce a bootpartition flip, but I wasn't able to find a timing that worked well. If there was a reliable way to do that, it would make reverting to the previous flash much easier: no need to bother with any networking, tftp, etc.
I also had some problems with the 32k nvram bug, so I tried flashing a version of the Asus CFE after modifying some of the embedded nvram defaults, but the lack of pulsing LED is really nerve-wracking when waiting to see if the router is bricked or not...
My initial Asus-CFE attempt ended up boot-looping a lot, and I could only sometimes get DD-WRT to finish booting. I suspect it might have to do with the watchdog timeout of "3000" that I copied from the Linksys CFE to the Asus CFE. The default from Asus was to disable the watchdog, and I think there may be some long delays during the Asus CFE start-up that are problematic.
I botched one of my later CFE update attempts and don't have a JTAG dongle handy, so my experimenting will be on hold for a couple days.
Since the Asus CFE source is available, I may try to recompile it with support for the proper power LED GPIO while I wait for my JTAG dongle to arrive.
Posted: Tue Mar 03, 2015 0:15 Post subject: Re: Experience with bad firmware flash and recovery.
p120ph37 wrote:
There is also a watchdog timer, which in some cases seems to cause reboot loops, but I haven't deciphered exactly when that can happen yet.
Since the Asus CFE source is available, I may try to recompile it with support for the proper power LED GPIO while I wait for my JTAG dongle to arrive.
i don't know why the watchdog in the asus cfe is disabled, but some asus firmware images actually update the cfe, so i'm wondering if there's an interaction there.
if you get an asus cfe with fixed gpio for ea6900 - let me know. i've done the same thing you have to make my e6900 more functional.
