long story, abbreviated v1.0:
got cisco e1000 v2.1 with stock firm on it.. flashed dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2 with success_ worked fine for a few but after initial fiddling and reset got a no response..
ALL lights BUT wireless are on steady.. did hard 30/30/30 several times with no luck.. bricked? do i need to go the JTAG route?
I've installed dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin on my Linksys E1000 v2.1 and it works great, but I have one problem with it. WPS light shines with orange light all the time, pressing the WPS button don't seem to work. Can anyone tell me what to do?
I've installed dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin on my Linksys E1000 v2.1 and it works great, but I have one problem with it. WPS light shines with orange light all the time, pressing the WPS button don't seem to work. Can anyone tell me what to do?
FYI, I bricked two v2.1 routers with this firmware. I had them setup as repeater bridges, one ran for a month and the other for about 2 weeks. Both just bricked overnight for no apparent reason.
I got a 3rd unit i flashed with the eko's 2.1 build posted in this thread and all seems well for the time being.
Posted: Wed Feb 08, 2012 5:26 Post subject: 30 second reset = bricked
bungfinger wrote:
hi all _ long time ddwrter first time poster..
long story, abbreviated v1.0:
got cisco e1000 v2.1 with stock firm on it.. flashed dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2 with success_ worked fine for a few but after initial fiddling and reset got a no response..
ALL lights BUT wireless are on steady.. did hard 30/30/30 several times with no luck.. bricked? do i need to go the JTAG route?
I have had a similar experience. Flashed with recommended firmware in this thread. Worked flawlessly for 5 months in wireless bridge mode. Went to do a 30 second reset (not 30/30/30) to prepare to use as normal gateway (wanted to do default setup again) and device did not come up on default IP address. I waited 5 minutes, still nothing, so I finally pulled power and reconnected. When I did so, all lights except wireless (and middle one over button - WPS?) came on, but very dimly, as soon as power was connected.
Tried 30/30/30 multiple times with no change in behavior. Thankfully, I was still in warranty and contacted Linksys for an RMA. I will probably use the replacement with stock firmware only because that will meet my needs at this time.
I flashed another of these units for use at a friends as an AP, and it has been working flawlessly form months. I now know I need to not try 30 second reset on these units going forward, but don't think the other one will ever need to be touched.
Posted: Wed Feb 08, 2012 6:31 Post subject: Additional details and clarifications
The FW file I used is dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin from pg 2 of this thread.
I did a little more research and several others report same symptoms as I had after 30 second reset. None so far was able to recover. At least one tried serial recovery and got nothing. From what I understand that means the CFE has been corrupted and the only remaining possibility appears in other threads to be JTAG recovery.
After doing a normal 30 second reset, is there a certain amount of time one should wait before ever unplugging power? I waited until a little while after all the lights came back to normal before I gave up on trying to connect and unplugged power. Immediately after reconnecting power it was in the "almost all lights solid and dim" state I mentioned above.
The FW file I used is dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin from pg 2 of this thread.
I did a little more research and several others report same symptoms as I had after 30 second reset. None so far was able to recover. At least one tried serial recovery and got nothing. From what I understand that means the CFE has been corrupted and the only remaining possibility appears in other threads to be JTAG recovery.
After doing a normal 30 second reset, is there a certain amount of time one should wait before ever unplugging power? I waited until a little while after all the lights came back to normal before I gave up on trying to connect and unplugged power. Immediately after reconnecting power it was in the "almost all lights solid and dim" state I mentioned above.
Same problem with my e1000 v2. (all leds softly on directly when powered)
Someone can confirm for the CFE ? I already sold some connector on the serial interface, I just need to interface some 3232 chip to try listening on serial... (please tell me the router boot as well to launch the serial daemon! )
So please, before i do anything, does someone have information about it ??
I click on that install guide, and that redirects me to "Linksys e1000v2 now supported" thread. So, I thought that is what I had to do (i.e. same process for v2.1 than for v2.0), and as in the first page says that "dd-wrt.v24-16758_NEWD-2_K2.6_mini_e1000v2.bin" is the one I have to use, I had tried to load this into the router (without any previous reset of any type, using an ethernet cable, and hardcoding 192.168.1.100 as ip address for my PC). I click on firmware update and I just let it begin. After reaching around 10% it answers back: "Firmware upgrade failed"
Is that a problem with the firmware or the router ???
After searching again I found the "Linksys E1000 v2.1
" thread where I read some confusing information.
At the end of it I read the official firmware for upgrading is the one in page 2, "dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin" . I also read people with instability of the router, and people that after flashing and performing a 30/30/30 reset bricked their router.
I also read people upgrading using "dd-wrt.v24-17990_NEWD-2_K2.6_mini_e1000v2.bin" with odd results ..
So bottom line:
1) The official wiki page points to the incorrect place
2) Hence, I had tried to flash with 16758 and the answers back from the router was "Firmware upgrade failed" (it was the first appearing in that thread)
3) In some parts of the V2.1 thread I read I must initially flash with 16968, and after that upgrading to newer versions
4) In some part of this V2.1 thread I read some tried to later upgrade with 17990 or other.
So: what should I do ?? What is the official release for initial flashing ? After flashing with that, what is the most stable version I should upgrade to ??
I click on that install guide, and that redirects me to "Linksys e1000v2 now supported" thread. So, I thought that is what I had to do (i.e. same process for v2.1 than for v2.0), and as in the first page says that "dd-wrt.v24-16758_NEWD-2_K2.6_mini_e1000v2.bin" is the one I have to use, I had tried to load this into the router (without any previous reset of any type, using an ethernet cable, and hardcoding 192.168.1.100 as ip address for my PC). I click on firmware update and I just let it begin. After reaching around 10% it answers back: "Firmware upgrade failed"
Is that a problem with the firmware or the router ???
After searching again I found the "Linksys E1000 v2.1
" thread where I read some confusing information.
At the end of it I read the official firmware for upgrading is the one in page 2, "dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin" . I also read people with instability of the router, and people that after flashing and performing a 30/30/30 reset bricked their router.
I also read people upgrading using "dd-wrt.v24-17990_NEWD-2_K2.6_mini_e1000v2.bin" with odd results ..
So bottom line:
1) The official wiki page points to the incorrect place
2) Hence, I had tried to flash with 16758 and the answers back from the router was "Firmware upgrade failed" (it was the first appearing in that thread)
3) In some parts of the V2.1 thread I read I must initially flash with 16968, and after that upgrading to newer versions
4) In some part of this V2.1 thread I read some tried to later upgrade with 17990 or other.
So: what should I do ?? What is the official release for initial flashing ? After flashing with that, what is the most stable version I should upgrade to ??
Yes indeed.. the wiki is incorrect (supported devices grid)for the 2.1. 16968 was the 1st build for this router. It can be found on page two of this thread.
After you make the initial flash, you can flash any build the router supports, but it must be post 16968 because that is the 1st build that supported this router. _________________ [Moderator Deleted]
Posted: Sat Mar 24, 2012 4:41 Post subject: E1000 V2.1 semi bricked
Well I did it. I've managed to get locked out of my E1000V2.1.
The sequence was:
1) Flashed with dd-wrt.v24-16758_NEWD-2_K2.6_mini_e1000v2.bin
2) Lots of configuration messing around and pushing some html files into the jffs area. Everything seemed to work as expected.
3) Decided that I needed more space for the jffs so I flashed dd-wrt.v24_nokaid_generic.bin. I didn't do a 30-30-30 before the flash. Don't know if that was the issue but the unit is now minimally responsive now.
I can get ping response IF I power up with the reset held then release the button after 15 seconds. If I do that it will give me 3 or 4 returns with TTL=100 and then nothing. I have managed to do a TFTP transfer using both the LinkSys package and with atftp from Ubuntu. Following a "successful" flash the ping response stays at TTL=100 forever (10 hours tested).
I have put in both the stock LinkSys FW and several variants of DD-wrt (including dd-wrt.v24-16758_NEWD-2_K2.6_mini_e1000v2.bin, dd-wrt.v24-17201_NEWD-2_K2.6_mini_e1000v2.bin, and 18774. None of them cause any persistent change in the router.
Here is what I think is going on:
The SystemOnChip goes past the "boot wait" before the "network switch" (a separate chip if I'm not mistaken) initializes. Holding in the reset button stalls the boot loader. THEN if the reset button is released after the network switch is ready the pings (and if your timing is right a tftp transfer) can interact with the boot loader and return TTL=100.
Having played with the timing I can transfer a .bin file into the unit about 1/3 of the time. Unfortunately the bootloader accepts the transfer into RAM but does not recognize the completion of the transfer so it does not actually write it to flash.
My feeling is that there an bug in the bootloader code that is beyond my ability to fix.
I would like to donate* the unit to someone who has serial and/or JTAG capabilities so that hopefully this issue can be further diagnosed.
* Donate or trade:
Exchange for an old (working) "G" unit that will support DD_WRT (I pay shipping both ways).
-- OR --
Donate (you pay the freight).
FWIW - I got the POS off the bay for $18.85 delivered do I'm not too worried about giving it away.
I'll post some captures of the Linux Terminal that shows the various ping responses during the power up w/reset sequence in a few minutes.
Posted: Sat Mar 24, 2012 5:31 Post subject: Ping returns for semi-bricked E1000V2,1
Here is the terminal output from Ubuntu during the Reset Button Power on Sequence mentioned above.
Code:
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
From 192.168.1.10 icmp_seq=667 Destination Host Unreachable
From 192.168.1.10 icmp_seq=668 Destination Host Unreachable
From 192.168.1.10 icmp_seq=670 Destination Host Unreachable
From 192.168.1.10 icmp_seq=671 Destination Host Unreachable
From 192.168.1.10 icmp_seq=672 Destination Host Unreachable
From 192.168.1.10 icmp_seq=673 Destination Host Unreachable
From 192.168.1.10 icmp_seq=674 Destination Host Unreachable
From 192.168.1.10 icmp_seq=676 Destination Host Unreachable
From 192.168.1.10 icmp_seq=677 Destination Host Unreachable
From 192.168.1.10 icmp_seq=678 Destination Host Unreachable
From 192.168.1.10 icmp_seq=679 Destination Host Unreachable
From 192.168.1.10 icmp_seq=680 Destination Host Unreachable
From 192.168.1.10 icmp_seq=682 Destination Host Unreachable
From 192.168.1.10 icmp_seq=683 Destination Host Unreachable
From 192.168.1.10 icmp_seq=685 Destination Host Unreachable
From 192.168.1.10 icmp_seq=686 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_req=687 ttl=100 time=4480 ms
64 bytes from 192.168.1.1: icmp_req=688 ttl=100 time=3471 ms
64 bytes from 192.168.1.1: icmp_req=690 ttl=100 time=1989 ms
From 192.168.1.10 icmp_seq=728 Destination Host Unreachable
From 192.168.1.10 icmp_seq=729 Destination Host Unreachable
From 192.168.1.10 icmp_seq=730 Destination Host Unreachable
From 192.168.1.10 icmp_seq=731 Destination Host Unreachable
From 192.168.1.10 icmp_seq=732 Destination Host Unreachable
From 192.168.1.10 icmp_seq=733 Destination Host Unreachable
From 192.168.1.10 icmp_seq=734 Destination Host Unreachable
The first 8 lines are with the power removed and the couple seconds after power on. Note windows gives this as "Hardware error".
The next 16 lines are with the reset button still pressed. The network switch inside the router is now functioning and accepts the ping but can't find 192.168.1.1 because the boot loader is being held up by the reset button. No return ping is generated. Windows calls this "Time out".
Then we get 3 valid ping responses from the bootloader.
After that the bootloader starts to attempt to boot and is too busy to respond to the ping. Again windows calls this a "time out"
There are a bunch of missing packets (#689, #691-727). I assume this is due to an unsuccessful attempt to start an ATFTP transfer in a separate instance of terminal. I wish I had a packet sniffer so I could see both the pings and the ATFTP traffic in true sequence.
I've read several other threads where people have had varying need to use the "reset at power on" method to get a valid ping. After seeing this I'm sure that it is due to a slow initialization of the network switch, which does have some logic and memory of its own. If the main processor (SOC) gets past the "boot wait" before the switch is ready then there is no chance of initiating a TFTP transfer.
I'd recommend that the "boot wait" be increased as a matter of course to help poor fools like me when it becomes necessary to try and recover from a bad flash.
FWIW - That would not help my current situation. As I stated above I did manage to load several various .bin files, none of which were actually "installed".
Posted: Sun Mar 25, 2012 3:22 Post subject: LED lights shining dimly
Folks,
If you have any of the following symptoms:
LED lights shining dimly
Router runs fine for months then suddenly stops passing traffic
Router won't reboot or reset
Traffic in router is sluggish
then your AC adapter wall wart MAY have gone bad. To save money Cisco went to switching power supplies in the wall warts instead of the older transformer/rectifier setup. You can tell the switching supplies because they are so much lighter. The problem is that they are CHEAP and (in my experience) have a high failure rate. And when they fail they don't always drop voltage when they are unloaded. Meaning that a DMM will measure 12v across the DC plug when the supply is plugged in the wall, but DC voltage will sink the moment the supply is plugged in.
I am seeing E1000's nowadays in the bargain bins at Goodwill, these are probably 1 year old routers - but they are being discarded because the power adapters have failed, not the router, and people don't know any better.
I am planning to purchase an used E1000 v2.1 wireless router. I wanted to ask if I flash it with dd-wrt.v24-16968_NEWD-2_K2.6_mini_e1000v2.bin and can I flash it again with dd-wrt.v24-17990_VINT_openvpn_jffs_small.bin to have JFFS.
Bought an E1000V2.1 to use as an access point. Read and followed Peacock thread to the letter. Flashed v24-16968 from Page 2 of this thread.
It said it flashed correctly, buy I cannot make ANY changes to the settings. If I try to change and save a setting, I immediately get a "Connection was Reset" error. If I go back to 192.168.1.1, nothing has changed. If I try to revert to stock firmware, or even reflash the prescribed formware, it goes back to this same "connection reset" page.