Posted: Sun Feb 08, 2015 17:04 Post subject: Bricked E2500
The state of my Linksys E2500:
It turns on, and is visible for pings for 3 or 4 times as 192.1.68.1.1, TTL=100, while the LED flashes on and then off. (The ethernet ports are always lit correctly based on connected cables.)
And then 192.168.1.1 disappears from the network, and doesn't come back. The LED _turns on and stays on_. I.e., this is not the 'cycling reboots' that a lot of other people seem to have.
From what I understand, these 3 or 4 pings are the 'tftp window' before the router boots the firmware. So that part is going correctly, and then it cannot find the firmware.
I have, several times, caught it during that window and uploaded firmware. I have done this both from a Windows 7 machine, and an old Linux Eee PC just in case there was some sort of problem with Windows 7. I've tried both the original firmware, DD-WRT firmware, and Tomato. This upload works, as far as I can tell. The upload finishes. I've sniffed the network, all the tftp packets are replied to, although I obviously don't know what's going on in the router.
And then, the router will, after firmware is uploaded, sit there forever responding to pings on 192.1.68.1.1 with TTL=100, with the power LED flashing. In case the router was actually doing something, I've let it sit for hours in this mode.
This is where I fall off the instructions, all of which seems to say that I should wait a few minutes and then 'something happens'. No. Nothing happens. Ever. The lights do not change. The router has sat for several hours like this. And, yes, I know tftp is sorta finicky, but I have done this half a dozen times, and as I said, it's not like the tftp is going away in the middle of this so the router can boot, which seems like everyone else's problem...the router is instead sitting there forever, respond to ping 192.168.1.1 with a TTL=100.
After I reboot, either normal reboot or a 30-30-30 reset, the router continues to operate exactly as before, not responding to anything except during the tftp window.
I have, additionally, tried 30-30-30 resets both after (waiting a hour after) firmware uploads, and at other times. I think I did those right. (The power light doesn't come on the last 30 until I release reset, at which point everything flashes and the router seems to do a 'normal' boot? Right? Except, of course, it gets nowhere.)
Nothing changes in the slightest.
I have also tried pinging the sole other address I've used of 192.168.254.1, and watched the network for *anything* coming from the router. I don't see anything.
I have also, solely because I read somewhere that it had helped, let the router sit for 48 hours unplugged. No change.
What do I do next? Is the next step 'open up the case and screw around with soldering wires to the things?'. I'm not really feeling competent to do that, *and* everything I read seems to say that if the tftp window is open and you can put firmware in there, cracking the case is not needed. So...what next?
Peacock announcement, note 6. You might need serial.
What did you do to create this situation. Also look into the cfe Nvram issue, discussed in note 1, but I don't know whether the e2500 has that problem. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
I have read note 6. My post was basically me recounting how I followed the steps in it. Note 6 and note 11 were the steps I was following.
Please look at note 6 and notice that there is *no solution* offered for my particular combination of problems.
There is no paragraph talking about what to do 'If all the lights are on, and you can ping 192.168.1.1 during boot, and only during the boot, and you can upload firmware via tftp, but *nothing ever changes*'.
The instructions seem to assuming that putting firmware on the router via tftp will result in that firmware actually being on the router, as opposed to what is happening with me.
Quote:
You might need serial.
If by 'serial cable' you're talking about some USB thing, this router has no USB port. Or serial port. Unless there's something inside it.
Quote:
What did you do to create this situation.
I attempted to flash firmware. I believe I was trying to upgrade Tomato from within the Tomato interface.
At this point, I do not care what firmware the router ends up with, as long as it actually boots.
Quote:
Also look into the cfe Nvram issue, discussed in note 1, but I don't know whether the e2500 has that problem.
It does not have that issue. I have successfully hard reset it previously, back when it worked and I screwed up some routing.
Posted: Sun Feb 08, 2015 19:28 Post subject: I can't get into that.
I saw that somewhere, and I have tried to get into it a few times. (I've actually seen Management Mode once before, back when this used to work, so I know the router has that mode. Can't recall how I got there.)
But I either can't get the timing right (I've tried holding reset everywhere from 1 seconds to 10 seconds.), or that trick doesn't bring up management mode on an e2500, or my router doesn't have enough firmware to do even that.
There is no paragraph talking about what to do 'If all the lights are on, and you can ping 192.168.1.1 during boot, and only during the boot, and you can upload firmware via tftp, but *nothing .
peacock announcement note 6 wrote:
but if none work and you can't successfully tftp proper firmware, you must use serial recovery or jtag to fix it. (See the Links to the Wiki articles on these, below).
You do realize there are three versions of this router, and if you flash the wrong firmware, it will not load or could brick it. Use proper oem firmware to flash. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
If I have to use a serial cable, I have to use a serial cable. However, if my problem is the router failing to install the firmware after it has been handed it, I don't actually see why a serial cable would help.
Does handing the firmware over by serial cable result in it writing it in a *different* way than it would using tftp? Because otherwise there's not much point.
Additionally I feel I should point my situation is not covered by that paragraph. I know, I read the thing a dozen times:
Some routers can be bricked even if they do give some ttl=100 responses to pings, but this is less common. Some routers can be bricked if the lights are not all lit, but again, this is not common. However, if the lights are all lit, and you cannot get a ping response, the router is definitely bricked. You can try the alternate recovery methods below, but if none work and you can't successfully tftp proper firmware, you must use serial recovery or jtag to fix it.
I *can* successfully tftp proper firmware. That step is a success. The router just, as far as I can tell, fails to install it after I upload it.
And that's not just me being nitpicky. That paragraph, in context, is clearly talking about situations where tftp doesn't work, including things like the router not responding to pings, or the lights not coming on at all. (Which probably means the bootloader is toast.) And thus tftp will, obviously, fail.
As opposed to what happens with me, where tftp very clearly succeeds, and then nothing changes.
If the intent of note 6 is to say 'you can't successfully tftp proper firmware, or you successfully tftp it but that doesn't change anything', than it needs to say that.
You do realize there are three versions of this router, and if you flash the wrong firmware, it will not load or could brick it. Use proper oem firmware to flash.
I am using the correct firmware. I have flashed this exact firmware to that router before.
Posted: Mon Feb 09, 2015 1:28 Post subject: I just read the serial recovery stuff.
It looks like all the serial recovery is supposed to do...erase the nvram, at which point I'd have to use the *same* tftp flash process that currently isn't working.
Someone please explain to me how that's supposed to help anything? The router *clearly* is not accepting firmware handed to the CFE via tftp. Pausing the router via serial cable and running the tftp flash command manually in the CFE is going to work vs....using it to send the flash to the CFE on boot, which currently doesn't work? Huh?
Remember, when I start uploading *now*, CFE clearly pauses itself and doesn't continue the boot, because I can keep pinging 192.168.1.1 forever and get TTL=100. The CFE is clearly accepting the firmware...it's just not *doing anything* with it.
So what exactly is a serial cable supposed to accomplish?
Or is the theory here that the hard-reset isn't working, so there's actually firmware now, but it has an invalid config? Why the hell wouldn't a hard reset clear that?
unplug/reboot
http 192.168.1.1
see if you can bring up Management Mode.
If so I would recommend the linksys FW_E2500_2.0.00.001_US_20140417.bin
If you don't have it it's probably around here somewheres or I can get it to you.
If you get the original to install you can check that all is well and start over with DD-WRT builds .... done this many times on several E2500 and a few others...good luck
Can't telnet. I don't think the telnet port is open during the CFE pause before loading the firmware (Or, at least, I can't time it right), and after that, the router is not on the network at all. My problem isn't that the router is rebooting (Which seems to be a much more common problem for people, and would let me in for a few seconds.), my problem is that the router *isn't* booting. It goes to CFE, during which I can do tftp, the power light flashes off and back on, and the router proudly sits there with the power light on and *completely unresponsive* to any outside interaction.
I literally have exactly three things I can do with this router. Add/remove power, hold/release the reset button, and tftp firmware to 192.168.1.1 during a ~5 second window, after which the router goes away. That is *all* the things I can do, and I have tried every single combination I can think of.
Here's a question: What, exactly, makes management mode come up? I've tried 30-30-30, I've tried 30-30-10, I've tried 'hold reset for 5 seconds during boot', nothing seems to bring it up. (And the reset button does physically work. It delays boot if I'm holding it down when I plug it in.)
I don't understand why, if the entire point of management mode is to recover from a bad flash, why I can't actually *get* to management mode when I clearly have had a bad flash. Why is *that* not a damn button on the router, or why doesn't *that* come up after 30-30-30?
I am aware that *erasing* the linux partition would probably bring management mode up (In fact, now that you've mentioned that, I think that's how I saw it before, a while back, although I recall the command being just 'erase linux'.), but I obviously can't do that if I can't get to the damn command line.
Is erasing the linux partition something I can do with a serial connection?
At least with the serial cable hooked up you can see what is going on.
They are less than $5 on eBay and should be in possession of every one that uses dd-wrt. _________________ I am far from a guru, I'm barely a novice.
I *can* successfully tftp proper firmware. That step is a success. The router just, as far as I can tell, fails to install it after I upload it.
And that's not just me being nitpicky. That paragraph, in context, is clearly talking about situations where tftp doesn't work
You are arguing with me about what I mean and telling me I mean something different?
You CAN'T successfully tftp firmware. If you did, you would not be getting ttl=100, which means no firmware was SUCESSFULLY flashed. So do whatever you want, but you bricked your router, likely by flashing the incorrect firmware, and now you need to clear it out properly with a cable. I have seen this hundreds of times before.
And Telnet will not work. You have no firmware on the router. Besides, MTD is a very dangerous command that can wipe everything and leave you needing jtag if used incorrectly and not all routers support jtag. Besides that command will just erase the kernel, which isn't there. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
You are arguing with me about what I mean and telling me I mean something different?
No, I'm pointing out that note 6 actually says something *different*.
You have now started talking about: which means no firmware was SUCESSFULLY flashed.
which is not what note 6 actually says: you can't successfully tftp proper firmware,
If the note means to say 'You can't successfully tftp *and flash* proper firmware', it needs to say that. The word 'successfully', as written, applies to tftping, not to flashing, which isn't even in that sentence at all! (And it's not *me* that's unable to do anything. It's the *router* that's not flashing what I gave it.)
I find it really odd you've insisting on conflating 'tftping firmware to the router' and 'the router flashing that firmware to itself', when my problem is the fact that one of those things does *not* follow the other. You may not making a distinction between 'successfully tftping' and 'successfully flashing', but I *must* make the distinction, because, duh, that is literally my problem.
And, as I pointed out, the previous two sentences of that paragraph are clearly talking about situations where tftp won't work at all, and the one before that makes no statement about whether tftp would work. So not only does the sentence literally means what I said it means, the implication of what that entire paragraph is explaining is 'If you *can't* upload firmware via tftp, blah blah blah', making it not at all relevant to someone who *can* upload firmware via tftp and the firmware is just being ignored.
I really don't care at this point, but don't imply I haven't read note 6 simply because I didn't telepathically determine what that paragraph in note 6 was trying to say instead of what the words in it said.
You CAN'T successfully tftp firmware.
Please explain what you would call these things:
1) Unable to make an tftp connection.
2) Able to make a tftp connection, able to start upload, something happens like the router rebooting, and tftp gives an error and halts.
3) Able to make a tftp connection, able to start upload, wait a bit, the upload finishes with a success.
I call the first two 'failed to tftp', and the last 'succeeded at tftp'. Whatever happens next can also succeed or fail, of course, but *it's not tftp*. tftp is a protocol for file transfer.
tl;dr: There is absolutely no indication, in the *entire* document, that correctly tftped firmware can be ignored by the router. None. There are warnings to wait to reboot after uploading, there are warnings you have to get the start timing exactly right and the router can be finicky, but not a single statement that 'The router can be broken enough to ignore what you have tftped to it even if you do it entirely correctly. And if, so, the router is bricked.'.
That really should be explicitly stated somewhere, not just some sort of hint about 'unable to successfully tftp', especially since that is not what is happening.
Go ahead and successfully tftp proper firmware then. If that doesn't work, then follow the information that I have now clearly posted in this thread, rather than arguing uselessly about what you think I meant in another thread.
peacock announcement note 6 wrote:
when we properly refer to a bricked router, we mean that it is not responding to an ethernet wired connection and needs a jtag or serial cable to fix it...
Some routers can be bricked even if they do give some ttl=100 responses to pings, but this is less common. Some routers can be bricked if the lights are not all lit. However, if the lights are all lit, and you cannot get a ping response, the router is definitely bricked. If you have properly flashed it, and cannot get firmware on, the router is bricked.
If you cannot get ttl=100 or ttl=64, (or you can but you still can't recover the router after trying all of the above) you will have to jtag or serial recover. Serial is safer and normally works.
peacock announcement note 11 wrote:
Be aware that sometimes you will get a success message when there has not actually been success. If you are trying to tftp proper firmware, and although it says "success" it is not actually flashing, you might need a cable to recover. See note 6, above.
Tftp is short for tftp.exe. Tftp.exe is a program, not a protocol. Ftp is a protocol. Tftp is an exe program, (not ftp written by tornado, like "tjtag" ) which I presume uses trivial file transfer protocol to flash. And I am engaging in denominalisation when I use "tftp" as a verb, not a noun. So when it says you can't successfully tftp I am meaning that the in using the program it does not SUCCESSFULLY flash. Successful, in this case, means that it actually worked.
So you need a cable. Indubitably. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Tftp is short for tftp.exe. Tftp.exe is a program, not a protocol. Ftp is a protocol.
I don't know why you think otherwise, but tftp is a protocol, exactly like ftp is a protocol. You know this, as you immediately mentioned its other name of 'trivial file transfer protocol'.
This is rather moot, though, as it doesn't actually make anything more logical when you claim that by 'tftping', you meant 'use tftp.exe' instead of 'tftping'. Well, tftp.exe returns success also!
Be aware that sometimes you will get a success message when there has not actually been success.
And *that* sentence sounds like you're talking about an implementation problem in tftp. So, assuming my tftp might be messed up, I tried different tftp programs, and then I went and watched the network packets to make sure the tftp *actually did* succeed.
Tftp is an exe program, (not ftp written by tornado, like "tjtag" ) which I presume uses trivial file transfer protocol to flash.
tftp.exe does not use anything 'to flash'. tftp.exe, being a program on a different computer communicating over IP, cannot flash router memory at all. tftp.exe uses the tftp protocol to *upload* a file (presumably firmware) to the router, which the *router* than flashes into nvram. (Technically, some specific program on the router does it, but whatever.)
This firmware upload can be done via means other than tftp.exe. For example, http, via the web interface. So you see why it's a bit confusing to pretend the subsequent flashing is somehow *part* of tftp.exe. By your terminology, connecting to the router web pages using Firefox and uploading a flash image that way would be 'make sure you've successfully Firefoxed the fireware'!
So, basically, my issue is: How is anyone supposed to know that when you talk about tftp succeeding, you mean tftp *and the subsequent internal nvram flash which no one can see* succeeding? (And how on earth would I know if that succeeded or not?!)
Actually, no, that's not my real issue. My problem is that not *only* is wrong terminology used, but your first response is 'Well, that's clearly covered in the note [assuming you can guess what definitions of words I've invented]', and then your later responses aren't 'Oh, I see what you mean, that is confusing, we should fix that', it's to pretend that your wrong terminology is correct.
And, again, I'm not some sort of pedantic ass here just looking for problems. The fact that the first thing, the actual tftp, is working, and the second part, which normal people would call 'flashing' but you insist on also calling tftp, apparently isn't working, is actually *important* to diagnose my problem.
People who are unable to do the first thing, whose router does not show up on 192.168.1.1 for a second, clearly have an *entirely different* problem than I do. (Possibly a broken CFE, which means, from what I understand, serial isn't going to work for them.) Same with people whose router reboots before they can finish tftp, they literally cannot 'successfully tftp' either, but their router isn't bricked at all, they probably just need to clear nvram and possibly the firmware.
Of course, part of this is due to the odd layout of the notes. Some sort of 'How far is the router getting the boot process, and here are the steps you can take to try to get it to the next step' layout would seem to be better.
If that doesn't work, then follow the information that I have now clearly posted in this thread, rather than arguing uselessly about what you think I meant in another thread.
Actually, no one has explained why, after I told them the router won't flash after being handed firmware via tftp to the CFE during boot, that they think it *would* flash if I connected via serial, paused boot at the CFE and...told the router to receive firmware via tftp?! That's the same thing!
Can someone explain why, exactly, that would operate differently? In both cases I would be handing firmware to the router (which is is CFE mode), via tftp to 192.168.1.1.
Is the theory that the router is, right now, moving out of CFE mode in the middle of my tftp, so doesn't flash? If so, why does it continue to respond to ping at 192.168.1.1 and flash the power light? It's clearly not trying to *boot*, because if it did, 192.1.68.1.1 would go away. So what is it doing, or not doing, and why would a serial cable change that?
