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.
In my experience with this router, the failsafe doesn't actually work. I have 2 of these devices that I use for experimental purposes, and I have ended up in seemingly bricked situations a few times (sometimes it was expected, other times it was a surprise. I have not tried using the serial port (mostly out of laziness), but when this has happened, the only way that I have recovered from a complete lack of network connectivity on these devices was to do the pin-short method. This is generally a bad idea most of the time and for most devices, but if all else is lost and the router would just be e-waste, give it a shot. Do it carefully so you don't short the wrong pins.
Prep:
download the firmware you want to flash onto the device.
set your computer to a static IP in the 192.168.1.0/24 range (anything but 192.168.1.1)
start a TFTP session, open 192.168.1.1, change to binary mode, and be ready to 'put' the file you downloaded.
open a window with a continuous ping to 192.168.1.1
connect a LAN port on the E3000 directly to your computer's ethernet port.
with the router powered off, short pins 8 and 9 on the flash chip (I use a very small screwdriver).
Holding the shorting-tool in place, turn on power to the router (I like the fact that the E3000 has a switch)
Keep the chip shorted for a few seconds, then release the short.
watch for the pings to respond with TTL 100.
send the firmware with the put command from the TFTP client.
the firmware transfer goes quickly, and the router will reboot automatically.
Then wait... and wait... and wait some more until you see the ping return TTL 64.
@isch - If/once you are able to un-brick the device, one other method you can use to reduce the probability of re-bricking is using an extroot setup. With extroot, the theory is that your config files would be contained on the USB stick, so a bad config would be revertible simply by removing the USB. This would get you back to a 'default' state (however you configure the device prior to performing the extroot process). At that point, any problematic configs could be edited/fixed simply by plugging the USB stick into another computer (ext4 capability required -- linux or a linux VM work most reliably in this case), or even by removing the stick during router boot, then plugging it into the router's USB port and manually mounting the stick so you can edit freely. Keep in mind that 'firstboot' would revert the whole router back to defaults, so you'd have to redo the extroot process. To avoid that, you could just store a known-good image of your usb stick on a computer so you have an easily accessible backup of the system in a useful extroot state.
@psherman Thank you for the information! I had heard of the flash short trick but was unsure if it would restore ethernet telnet access as every example I had read about was suggesting following it up with serial access. It is reassuring to hear that you have done this before.
An update on my side: I'm confounded on how to get the case open. I know there are plastic clips holding the top in place, but have been unsuccessful in prying them open. Do you have any advice on what tool might work well? I almost stabbed myself with a flathead screwdriver earlier and am loathe to repeat that.
I think the biggest propblem I will face with the LEDE install is getting the 5ghz radio to work. I was planning to follow the advice here: Linksys e3000 with LEDE - is this accurate to your knowledge? If I intend to do any other risky things in the future, I'll consider the extroot - again thank you for sharing that. It could be invaluable in saving me time some day
@isch - I'd recommend a nylon 'spudger' which can be handy for lots of other stuff, too.
I don't recall which wifi kernel extensions I installed to get the 5GHz wifi to operate properly (and for that matter, I think the 2.4 GHz radio was only able to run @ 802.11g speeds).. I got it working, but then tried another driver and ended up with a bricked unit (requiring the pin-short to recover). I gave didn't try again because I don't actually care about wifi on the E3000 since I just use it for experimentation with various LEDE/networking things (I actually was just using it the other day to simulate a router-on-a-stick VLAN configuration to interface with a new smart switch so I could verify that my setup would work).
Anyway, good luck opening the device and doing the pin-short method of recovery, and be careful with your tools -- not worth minor injuries to open the case!
Shorting pins is dangerous - and given the hard set size limit for automatic tftp recovery (around 3.x MB) I don't see how that could work either. Invoking the tftp procedure over the serial console (without that broken size limit) does work reliably though.
@slh - I agree that the pin-short method is generally a bad idea and can presumably irreparably damage the router if you short the wrong pins. It was actually my last resort method since I didn't have a serial adapter handy and the unit was otherwise headed to the trash. And I was surprised at the fact that the method really does work. The TFTP transfer method has worked for me with both the stock firmware and the standard LEDE 17.0.x images, but I could certainly see how it could fail if you tried to install a larger image.
It is probably safer to use the serial port method when possible, though. In this case, it is mechanically a bit of a PITA to get the serial connections out (and most people will need a USB to serial adapter handy), but it is, without a doubt, less likely to cause hardware damage if you mess up.
I was able to get the case open with the flathead eventually, though did break some clips along the way. Ce la vi!
Check out the jumper that my electrical engineering buddy put in an easy and safe method of doing the pin short, and repeatedly if necessary!
I turned the device on with the jumper removed, then placed it after a second and removed it again after several more seconds. The router responds to ping with TTL 100 after a few add'l seconds, and I am able to TFTP the same LEDE firmware successfully! Thank you so much for the instructions and help out with this @psherman!
Heres where my next problem comes in though: It never reboots. When I restart it, it continues to be nonfunctional. I can repeat the method, but the same thing happens. It is suspect that the TFTP upload completes nearly instantaneously. I think this problem might be related to the image size limit that @slh referred to above. I'm going to try again with something smaller like dd-wrt mini and report back.
@isch - Nice! I have contemplated the same mod, but I would wire in a momentary switch or button on the back of the case or something so I could have it all buttoned up. Although the risk there is that you could easily end up accidentally resetting the router, so, yeah, the jumper is probably best. You might want to stick a little hot-glue on the wires -- tack them down to the board so they are less likely to move and break off the pads of the chip.
Anyway, I assume you've followed the procedure I described, including the switch to binary transfer mode in the TFTP program, right? Did the TFTP program indicate a successful transfer? How long did you wait before you power-cycled the device? I found that it was many minutes before it would automatically reboot. I don't remember how long, but it really seemed like it would never do it and then suddenly it did. You could just run a continuous ping and just let it sit there for 30 mins or so after completing the transfer -- hopefully you will see it eventually go offline and then back with TTL=64.
Also, what firmware did you try using? You might try installing the stock firmware if LEDE doesn't seem to be working. You can then use the stock firmware to upgrade to LEDE again.
@psherman Bad news, friend. I spent a good number of hours putting in the time waiting for the router to do its thing and it was all for nothing. Tried dd-wrt mini, which gave me an the 'code pattern incorrect' error, LEDE just immediately finished the transfer and never rebooted, and with the stock firmware, I don't even remember but they were all no dice, man.
I waited at least 30 minutes in between each attempt, rebooting and re-shorting the router each time. I think it's irrecoverably bricked. I'm tired of working on it, to be honest. Maybe I'd be able to get further by soldering a serial cable to it, but I don't think I care enough anymore. My coworker gave me a replacement, but this might just signify my end of using consumer routing hardware. It's cheap enough to put together your own tiny PC to use as such nowadays. And the benefits of running a linux distribution like pfsense that is built for routing and that you have complete control over are very attractive. Especially considering I already know how to administrate a linux system.
Thanks for all your help, though, I seriously appreciate the conversation and knowledge exchange. Wish you all the best!
Bummer about the E3000, but as you point out, it's not really worth much more effort than you've already given it.
My experience with consumer grade networking hardware has been mixed, too -- I find that the OEM firmware is usually pretty bad, but the raw performance of the device with certain chipsets (broadcom in particular) is pretty well optimized (within the constraints of the hardware itself). Installing LEDE gives much more power and flexibility, but sometimes lacks in wifi performance with Broadcom chips (works reasonably well for Atheros, though).
As for networking hardware -- I've now moved to UBNT. I use an EdegeRouter X and a pair of UAP-AC-PRO units. But I use LEDE for running OpenVPN servers (using various hardware) and also travel routers (MR3020 and WR902AC) with OpenVPN client config to connect back to my servers when traveling.
I'm a huge fan of LEDE, but on the hardware side I've been happy with UBNT and I've been using their firmware (although it is not quite as easy to use). I've never really played with pfsense, but keep in mind that with an x86 system, you could always try running LEDE vs pfsense to figure out which one is best for your needs based on features/integration, ease of use, etc.
Anyway, good luck with the next round of networking!
