On Thu, 17 Aug 2006 08:19:51 -0700 Jeff Liebermann <(E-Mail Removed)> wrote:
| Tony Hwang <(E-Mail Removed)> 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.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net /
spamtrap-2006-08-17-(E-Mail Removed) |
|------------------------------------/-------------------------------------|
Similar Threads
Linear Mode
