Trying to resurrect a dead Linksys WRT54GS router

andrewmemoryblog@gmail.com (Andrew's Memory Blog) — Mon, 01 Sep 2014 01:47:09 -0700

I recently went through heroic efforts to bring a dead Linksys WRT54GS router back to life. These routers are great for Broadband Hamnet so I really wanted to get it working, but no dice.

But I don’t want to forget what I did, so I’m documenting it here.

Fix the hardware
#

The first problem was that the router made a strange buzzing sound. I opened the router and discovered that LX2 in particular, but also LX1 (two chokes at the power supply input) were actually vibrating when I put my finger on them. In addition, the capacitors near it were hot to the touch.

This was described in this post as an electrolytic capacitor problem. Sure enough, when I replaced CX2 with a new 220 uF 25 V electrolytic capacitor, the device settled down. At this point, the power LED was flashing (a bad sign) but at least it was now flashing at a regular speed. While I was soldering, I took the time to add a 12-pin header to the router’s JTAG port.

Reflash the Firmware
#

Following the unbrick article here, I wasn’t able to ping the router. No matter what, I’d get “destination host unreachable” - even though my IP was the same as the router, ostensibly. So I figured flashing was required.

I started out by trying to get a SEGGER J-Link talking to the JTAG port. I used the pinouts for the WRT54G described here for the WRT54GS, and the pinouts for the J-Link described here. Note that RESET on the J-Link is nSRST on the WRT54GS.

After I’d done that, I wasn’t able to get the J-Link talking. It looks as if the J-Link software wants to talk only to devices it knows about - or at least, that’s all I could figure out about it. Trying to set it to MIPS mode to impersonate EJTAG didn’t yield any success either.

So it was time for a different option. I didn’t have a parallel port handy, but I did have a Raspberry Pi. And a wonderful individual has taken the time to port tjtag to the Raspberry Pi. I cloned the Git repo to my Pi and built it. I had to use:

git clone git://github.com/oxplot/tjtag-pi.git

to grab the Git repo, since https wants an auth key and I don’t have one. After that I followed the Setup instructions and got tjtag built.

I connected things up as described in the wiring diagram, and had success! I was able to probe the router. (I had to run sudo ./tjtag -probeonly instead of just ./tjtag.)

Then I went off to the tjtag instructions here. The first few times I did:

sudo ./tjtag -backup:cfe

I got different results. It appears that tjtag on the Pi spends so much time sending output to the console that it messes up its timing. So I redirected the output to /dev/null, and after that I got consistent backups.

Once I had an nvram backup, I tried erasing the nvram:

sudo ./tjtag -erase:nvram

This worked, but didn’t solve my problem. So I thought I might have had a corrupted CFE. I located the CFE for my router here and modified it to have my IP addresses using imgtool_nvram. I used the following command:

imgtool_nvram.exe wrt54gs1.0-CFE.
BIN et0macaddr=00:11:22:33:44:55 il0macaddr=00:11:22:33:44:56

(substituting my real MAC address and one higher than it.) Then I dumped that back on the Pi as CFE.BIN, and did:

sudo ./tjtag -flash:cfe > /tmp/out

That worked, but still no joy in Mudville after I did the flash. No matter what, when I pinged I got destination unreachable. I wondered if it was Windows messing with me, so I booted to Kali to see what happened there. Still no dice.

Finally, I thought it might be a bad kernel, so I nuked it:

sudo ./tjtag -erase:kernel

Even with that, the router’s still not responding. Other than re-reflashing the CFE on the assumption that the bad kernel corrupted it, I’m out of ideas.

Drat, I thought I had it when I saw the instructions about setting the address with arp. (arp -s 192.168.1.1 aa-bb-cc-dd-ee-ff if you’re on Windows.) But even when I did that (using the MAC address that I flashed), I still had nothing. I even stuffed Wireshark on the end to listen for any packets. He’s dead, Jim.

Connecting to HSMM-Mesh and the Internet from a laptop

andrewmemoryblog@gmail.com (Andrew's Memory Blog) — Sat, 03 Aug 2013 17:39:03 -0700

Note: This page does not discuss connecting HSMM mesh to the Internet. It’s just about talking to the mesh and the Internet from the same client device.

I’ve been playing with hsmm-mesh lately on my laptop. Up until now, when I’ve done this I could either view the HSMM mesh or the Internet, but not both. There were a couple of reasons:

1. My routing tables didn’t know how to direct traffic to the HSMM mesh network.

To solve this, I needed to tell the laptop to send traffic in the 10.*.*.* range to the HSMM mesh rather than to the default gateway:

ip route add 10.0.0.0/8 via 172.27.0.1 dev eth0

2. I had to make sure things were resolving right for DNS (in my /etc/resolv.conf):

domain austin.tx.us.mesh
search austin.tx.us.mesh
nameserver 172.27.0.1
nameserver 192.168.1.1

DNS is still a bit of an issue. 172.27.0.1 resolves anything in *.austin.tx.us.mesh, so my local network is never found. But at least I can browse the web and HSMM.

Hsmm on Andrew's Memory Blog

Trying to resurrect a dead Linksys WRT54GS router

Fix the hardware #

Reflash the Firmware #

Connecting to HSMM-Mesh and the Internet from a laptop

Fix the hardware
#

Reflash the Firmware
#