Tomato Toastman's Releases


Here's a guide from DD-WRT on TFTP recovery flashing. Use a known good firmware file ( preferably the one you were using before this latest flash that bricked the router ) . Give it a read through.. if I can be of help or answer specifics I'm happy to do so.

https://www.dd-wrt.com/wiki/index.php/TFTP_flash
In the end, I couldn't recover from its bricked state. I was able to TFTP the Tomato firmware and it said it flashed successfully but it still does not boot up.
 
In the end, I couldn't recover from its bricked state. I was able to TFTP the Tomato firmware and it said it flashed successfully but it still does not boot up.
What exactly is the routers current behavior? When turned on, do the LEDs exhibit abnormal on/off/blink states? When a computer is connected via ethernet cable to the router, does the router respond to pings at 192.168.1.1 consistently? What error is being returned when you attempt to access the GUI webpage.. timeout, connection refused etc.
 
And I trust you have used the reset button on the back of the router? While powered on, pressing and holding the reset button for 10 seconds and then releasing. And then with the router powered off, press and hold the reset button.. while still holding the reset button turn the router on. Continue holding the reset button for 15 seconds and then release.
 
after the flash try, remove power hold in reset for 30 seconds and while continuing to hold in reset, connect power and hold for 30 more seconds than let go of the reset. See if that will work. There are some other reset boot ups but i don't remember them all.


lol....Sean B.
 
What exactly is the routers current behavior? When turned on, do the LEDs exhibit abnormal on/off/blink states? When a computer is connected via ethernet cable to the router, does the router respond to pings at 192.168.1.1 consistently? What error is being returned when you attempt to access the GUI webpage.. timeout, connection refused etc.
Thanks Sean for trying to help out.

Prior to you positing the guide on how to tftp, I've already done those via the tftp.exe utility as well as via the command line. Anyways in my case the E4200 is in a continuous boot loop. Hence, when I tried to flash the stock Linksys firmware, the process stops in the middle - as in the utility will show the status bar and after midway, it fails. I tried flashing the smallest tomato firmware version, the utility shows it successfully flashed. But even after waiting 5 minutes and then pressing the reset button 30/30/30, the router is still inaccessible - LAN1 has activity and ping-able but I still cant access the web gui and the boot loop continues

Thus I believe only a jtag can save it...

P.S. Stupid question, can I do an NVRAM erase via command line without jtagging - I assume not, no?
 
Thanks Sean for trying to help out.

Prior to you positing the guide on how to tftp, I've already done those via the tftp.exe utility as well as via the command line. Anyways in my case the E4200 is in a continuous boot loop. Hence, when I tried to flash the stock Linksys firmware, the process stops in the middle - as in the utility will show the status bar and after midway, it fails. I tried flashing the smallest tomato firmware version, the utility shows it successfully flashed. But even after waiting 5 minutes and then pressing the reset button 30/30/30, the router is still inaccessible - LAN1 has activity and ping-able but I still cant access the web gui and the boot loop continues

Thus I believe only a jtag can save it...

P.S. Stupid question, can I do an NVRAM erase via command line without jtagging - I assume not, no?
Does sound like you've covered all the bases. As far as NVRAM reset, I *believe* the reset button on the E4200 should do that. However, this following procedure may be worth a shot as I'm not sure if it's a per device or per firmware ( tomato ) implementation but does specifically erase the NVRAM on my RT-AC68P: With the router off, press and hold the WPS button ( the blue button the back ) and turn the router on while continuing to hold. On my 68P after about 15 - 20 seconds the power LED will begin to flash rapidly indicating NVRAM has been cleared. If you get the same response, that would be a great sign and upon releasing the button it should reboot. If not, hold for a total of 30 seconds just in case and then release. Observe for indications the router is rebooting.. if it is, let it reboot and cross your fingers. If not, shut it off.. offer it a cookie or perhaps a shot of top shelf whiskey.. then turn it back on and see what it does ;) .

**EDIT**: Sorry, I didn't really answer your question about the NVRAM. If you were able to get into the router via a telnet/ssh shell then yes, you could clear the NVRAM via command line. However there is no "external" program or access avenue ( command line or otherwise ) that can specifically induce an NVRAM clear. If telnet/ssh connection, http GUI access, TFTP recovery, and hardware ( button ) avenues are all non-responsive then the only options left would be a UART serial or JTAG connection. UART being the much easier and preferable method of the two if available on the board.
 
Last edited:
It appears the E4200 has both UART serial and JTAG ports, both are un-populated through-hole connections. The serial port is labeled JB2.. I've attached a surprisingly high quality picture I was able to find. However, I would highly recommend soldering in a standard pin header rather than the extremely bad and rather scary bare wire to pad attempt shown. And please note, I am unable to confirm the accuracy of the pinout shown as I do not have access to this model of router. All info or help on the subject of UART/JTAG connections I provide in this and any future posts is to be used at your own risk.

znrhx2.jpg

e4200_serial_pinout_981.jpg
 
Last edited:
It appears the E4200 has both UART serial and JTAG ports, both are un-populated through-hole connections. The serial port is labeled JB2.. I've attached a surprisingly high quality picture I was able to find. However, I would highly recommend soldering in a standard pin header rather than the extremely bad and rather scary bare wire to pad attempt shown. And please note, I am unable to confirm the accuracy of the pinout shown as I do not have access to this model of router. All info or help on the subject of UART/JTAG connections I provide in this and any future posts is to be used at your own risk.
Sean B, if I wanted to try to revive this router using the serial port on the E4200, and do this as cheaply as possible, I was perhaps thinking of purchasing any needed parts from Ebay through the cheapest China or other Asian seller that I can find. It would take over a month for stuff to ship to me from there but I am in no hurry. What parts would I need such as a USB to Serial cable, standard pin header, etc.? I'm not sure of the terminology to search for on Ebay. Also, does there have to be any soldering involved or can a pin header (if I can find it on Ebay) just be placed into place there temporarily? Thanks for any help that you may be able to offer.
 
@Dent You need:

1. A USB TTL cable (such as this) that can do 3.3V serial (yes, it matters - 5V serial and 3.3V serial are very different),
2. To know what the serial port speed/stop/parity bits/flow control should be set to,
3. To solder pins to the actual E4200 mainboard so that you could use the above cable. Soldering the wires of the USB TTL adapter directly to the mainboard is ridiculous, IMO.

When hooking up the cable, ONLY HOOK UP TxD AND RxD AND GND. DO NOT HOOK UP VCC!

Be aware that many of the depictions of pinouts I've found online depict the TxD (transmit) and RxD (receive) pins backwards (one such example -- different router, but my point stands). The authors of these pictures sometimes depict "what wire on your adapter to place here" and not what the actual pin functionality is, which is utterly stupid (i.e. backwards). Point is: TxD pin connects to RxD wire, RxD pin connects to TxD wire. If you get these mixed up (e.g. TxD<-->TxD), some devices will misbehave very badly (for example the RT-AC56U upon power-on will light up all its LEDs, then just sit there with the LEDs lit, as if you've permanently damaged the device).

I have to assume there's a CFE. If there isn't, then JTAG might be your only option. If there is a CFE, then you'll need to see if it the CFE it provides has a TFTP server so that you can transfer a firmware to the router from a client. Some CFEs have a TFTP client (i.e. the CFE fetches a firmware from a TFTP server), but have a 256KByte limitation on their transfer limit (i.e. you can't transfer a firmware this way).

Otherwise, if it's purely an NVRAM thing and the CFE offers NVRAM manipulation (most do!), then you can just manipulate NVRAM directly from the CFE.

P.S. -- Are you doing this purely for a fun project, or are you really trying to save the device out of dedication? If the latter: the E4200 is almost 4 years old, I'd suggest possibly just buying a different/newer router. It would be the easier choice.
 
@Dent....
P.S. -- Are you doing this purely for a fun project, or are you really trying to save the device out of dedication? If the latter: the E4200 is almost 4 years old, I'd suggest possibly just buying a different/newer router. It would be the easier choice.
This was purely for a fun project. I already purchased a used Asus RT-N66u for a replacement. If it was very cheap and easy to fix, then I would try it. If not, then I would just throw it away. I don't own a soldering iron and would not buy one just for this. I've read they make solderless/push in/press in pin headers but ebay doesn't really have much or extremely cheap. This may be too involved for me.
 
Depending on the particular router's pcb, sometimes the pin headers are quite a tight fit in the board, or you may be able to get away without soldering it if you stress the header against the pcb. Or you can buy a throwaway Chinese made soldering iron, which cost peanuts.

BTW: The RT-N16 was able to be flashed in the same way that SeanB suggested in in post 4029, using the WPS button. That reset it to 192.168.1.1. After that it could be placed in recovery mode as normal.

EDIT - My gut feeling, having had years of experience with fixing broken routers, is that yours is not bricked and I'm almost 99% certain that it can be flashed by tftp. You just have to keep trying, I sometimes tried for hours before things suddenly worked.
 
Depending on the particular router's pcb, sometimes the pin headers are quite a tight fit in the board, or you may be able to get away without soldering it if you stress the header against the pcb. Or you can buy a throwaway Chinese made soldering iron, which cost peanuts.

BTW: The RT-N16 was able to be flashed in the same way that SeanB suggested in in post 4029. That reset it to 192.168.1.1. After that it could be placed in recovery mode as normal.
Yes, I have tried as per post 4029 but nothing worked. Do you know now what exactly happened that caused this brick situation in this particular model of router and why the TFTP flashing of the firmware does not work?
 
@Dent If you're in the United States and you feel like spending a little bit of money, you can mail me the E4200 and I can attempt to recover it for you (I'm happy to pay return shipping), including possibly leaving a permanent pin connection for serial + including a free USB TTL adapter if asked. The TFTP method is "tricky" a lot of the time, and I've found several TFTP clients that don't behave correctly (both on Windows as well as Linux).

I would not trust push-in solderless pins. They aren't going to make a good connection.

There's no real way to determine "what" "bricked" the unit (I use quotes around brick because I simply can't tell if it truly is or isn't). It's not like there's magical permanent-storage logs that hold such information. :) I'd rather not speculate as to the cause.
 
@Dent If you're in the United States and you feel like spending a little bit of money, you can mail me the E4200 and I can attempt to recover it for you (I'm happy to pay return shipping), including possibly leaving a permanent pin connection for serial + including a free USB TTL adapter if asked. The TFTP method is "tricky" a lot of the time, and I've found several TFTP clients that don't behave correctly (both on Windows as well as Linux).

I would not trust push-in solderless pins. They aren't going to make a good connection.

There's no real way to determine "what" "bricked" the unit (I use quotes around brick because I simply can't tell if it truly is or isn't). It's not like there's magical permanent-storage logs that hold such information. :) I'd rather not speculate as to the cause.
I actually live in Canada so I don't believe shipping is really cost effective. Thanks for the offer, anyways.
 
This was purely for a fun project. I already purchased a used Asus RT-N66u for a replacement. If it was very cheap and easy to fix, then I would try it. If not, then I would just throw it away. I don't own a soldering iron and would not buy one just for this. I've read they make solderless/push in/press in pin headers but ebay doesn't really have much or extremely cheap. This may be too involved for me.
If this attempt is based out of fun/curiosity ( implying the end result and possible damage caused by the attempt is not a big deal ) and soldering is a concern then feel free to improvise. Use bare wire ends and fashion a way to get them to maintain contact with the copper rings of each through-hole. Possibly sticking a section of stripped wire through the hole, folding each side down to a moderately taunt state and then use a common arts-an-crafts hot glue gun and put a small dab top an bottom.. then cut any excess wire left sticking around on the bottom so they don't manage to short to anything else. Or perhaps get some mini-hook test clips ( pictured below ) at a local electronics store or on ebay.. can get a 5-pack for a couple bucks. Flatten the hook end so it's L shaped and cut the foot of the L to a width that just barely fits through the hole. Worst case ( barring missed stray wire strands causing a short ) would be there isn't enough contact and you won't get a terminal connection, or just barely enough contact resulting in randomly lost connections and/or jibberish appearing in your terminal programs console.

31182-1.jpg
 
Last edited:
Hi Toastman,

Although I find myself in an unfortunate situation with no live Internet connection at home to test this on properly (such hard times!), I can confirm that your 511.2 mini build for the e1200 v1 flashed successfully!

Current version = 1.28.0511 MIPSR2Toastman-RT-N K26 Mini

Many thanks again!
 
Small bug in the latest on a R7000, in bandwidth limiter i am unable to change Priority as it stays on low in Default Class for unlisted MAC / IPs in LAN (br0).
It could be that it is changing but the gui is reporting it at Low.

Apart from that eveything is running great.

Thanks.
 
Last edited:

Back
Top