OpenWrt Forum Archive

Topic: Linksys e3000 debricking help?

The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I have a Linksys E3000 with a USB port. I was running the last released tomato toastman build previously. I wanted a more recent image though, so I flashed to stock, then flashed to lede-17.01.2-brcm47xx-generic-linksys-e3000-v1-squashfs.bin as recommended in the hardware table. Everything was fine. I then tried to bring up the 5ghz radio before installing additional packages that were required. I did not think this would result in a brick, but it did.

The router was in near-stock configuration before this happened with a WAN address of 192.168.1.1. I have configured my ethernet adapter with a static IP of 192.168.1.2/24 and default gateway of 192.168.1.1.

Sequence of LED events corresponding to ping activity:
- First thing the router does when it turns on is illuminate all LEDs solid briefly before all but power going out. Power blinks rapidly. Center LED above wifi button is white.
- Power blinking rapidly following by LAN indicator for the port that is plugged in coming on to blink unpredictably. This occurs for about 20 seconds. Ping responds general failure, reply w/ TTL 100, request timed out, then replies with TTL 64.
- All lights go out except power which continues to blink rapidly. All leds except USB and Wifi symbol come on. LAN indicator for port that is plugged in blinks unpredictable with power blinking rapidly. Ping responds general failure followed by request timed out.
- Power continues to blink rapidly with LAN in the same fashion, but then light above Wifi button comes on solid orange with the Wifi indicator next to it. Ping replies with TTL 64 followed by request timed out. This occurs for about 5-10 seconds.
- Cycle repeats.

If I power cycle it, the sequence of these events sometimes are in different order - mainly the two major LEDs going out followed by flashing. At the points where the LEDs all go dark, my PC's adapter reports down and this is reflected by General failures. When the router is responding to ping, I can access the LUCI GUI. I cannot log in. I cannot do anything before connectivity is lost. These periods of responsiveness are around 3-5 seconds.

30-30-30 or 30-5-5 reset does nothing to change this behavior. Holding reset while trying to navigate to the UI does not deviate from the behavior above - if I hold the reset button longer than 30 seconds, it stops responding to ping altogether.

I have booted the router into failsafe mode by rapidly pressing the wifi button after boot. In this mode, the power LED flashes rapidly and the LAN port that is plugged in blinks as if data is being transmitted. When I try to telnet to it, I get 'no route to host.' I have performed a packet capture, and find it is not responding to ARP. It is not responding to any packets sent to it.

Is there any chance of saving this thing without soldering to the serial pinout exposed through the WAN port? I do not have the cable for this, and was hoping that maybe there is something that I could do to revert the bad configuration I mistakenly made and be on my way. I have browsed a bunch of forum posts and wiki pages, but this is not my forte.

I actually just started having the same issue with my E3000 (just switched from DD-WRT a couple days ago).  Initial install went fine.  I started making some changes to put it in client mode and started having problems.  Also can't telnet when booting it in safe mode.  Not booting it in safe mode makes it go in an endless cycle of rebooting.  For a while, I was able to ping it briefly during each cycle on the IP I had set it up with (10.0.2.1), but even that doesn't work now.  30-30-30 reset also doesn't seem to work for me.

Running tcpdump without restricting port/protocol, I do get occasional UDP packets on port 5355 and 5353.  Looks mostly like garbage with the occasional human-readable segment "_ipps._tcp.local".  No idea what it means, though.

The discussion might have continued from here.