Blown firmware

this might give a few pointers....

Tony Hwang hath wroth:

Nice work. Just ignore the multiple warnings not to do firmware upgrades via wireless. The problem is that the new firmware overscribbles sections of active code if done via wireless. The wireless connection hangs and the upload never finishes.

There are several web pages discussing "debricking" a WRT54G. The proceedure is similar. Use a TFTP client to upload the bin file. You can tell if you have a chance by setting up a workstation with a static IP address of 192.168.1.5 and trying to ping the IP of the router at 192.168.1.1. Start the process with: ping -t 192.168.1.1 Then turn the SRX400 router off and back on. Within a few seconds, the pings should start returning echos, but then stop after about 1 minute. It's during this interval that you have to initiate the TFTP file transfer.

I'm not sure if any of this will actually work because the various debricking proceedures are based on Broadcom chipsets and the SRX400 is Airgo based. Probably not, but it's worth a try.

Another method is to find and use the JTAG port for firmware loading, but I have no information on its location, available commands, or proceedures.

On Thu, 17 Aug 2006 08:19:51 -0700 Jeff Liebermann wrote: | Tony Hwang hath wroth: | |>Linksys SRX400 wireless router. Firmware is corrupt. |>Router is dead now. |>Anyway to recover it? Any suggestions. Long story not |>using wired connection during f/w update. | | Nice work. Just ignore the multiple warnings not to do firmware | upgrades via wireless. The problem is that the new firmware | overscribbles sections of active code if done via wireless. The | wireless connection hangs and the upload never finishes.

While there are enough good reasons not to do firmware upgrade over the wireless link, incorrect programming of the code itself should never be one of the cases. If the code that receives the firmware image in RAM disregards the existing use of that RAM when allocating memory, then such code is improperly programmed. If the memory needs of an active wireless link and the memory needs of updating the firmware are in conflict, such as because insufficient RAM exists to do both functions, then the update logic should shutdown the conflicting processes before acceping to data (which would go no further than stalling the update if the stream was coming over the wireless link, rather than corrupting it).

| There are several web pages discussing "debricking" a WRT54G. The | proceedure is similar. Use a TFTP client to upload the bin file. You | can tell if you have a chance by setting up a workstation with a | static IP address of 192.168.1.5 and trying to ping the IP of the | router at 192.168.1.1. Start the process with: | ping -t 192.168.1.1 | Then turn the SRX400 router off and back on. Within a few seconds, | the pings should start returning echos, but then stop after about 1 | minute. It's during this interval that you have to initiate the TFTP | file transfer. | | I'm not sure if any of this will actually work because the various | debricking proceedures are based on Broadcom chipsets and the SRX400 | is Airgo based. Probably not, but it's worth a try.

To the OP: In some cases, devices like these have very short time frames in which to make a TFTP connection. Many TFTP clients do have a mode to make them keep trying to start the transfer, and this mode might be needed. I've heard of cases as short as 5 seconds after power on checks are done.

Though I doubt it in this case, a few devices use other IP addresses as the initial address. Pinging a broadcast address may reveal it or may not. I've even heard that some require the TFTP be done from a specific IP address. If what Jeff suggests does not seem to be accepted, you may end up having to try potentially all the other 252 addresses.

You should also do this with a hub or switch between the PC running the client and the router, with nothing else connected. This is to eliminate any potential confusing traffic (the logic may terminate TFTP early when it sees one frame that isn't TFTP), and to keep the link up while the router is power cycled (which may not happen if a direct crossover cable is used).

| Another method is to find and use the JTAG port for firmware loading, | but I have no information on its location, available commands, or | proceedures.

I could not find any online by Google, either. Someone who has done a JTAG reload before could probably recognize the convergence of data lines to where the header is, or more likely is absent, on the board.