Linksys WRT54GL Router: Brick Testing & Debricking

I had a Linksys WRT54GL v. 1.1 router, running in Windows 7.  The router did not seem to be functioning properly.  I wanted to find out whether it was "bricked," as they called it -- whether some tinkering on my part, or some power surge, or something else had turned it into a useless brick, a paperweight.  I wanted to get it back into service, if I could, and I also wanted to look into the possibility of upgrading its firmware while I was at it.  This post describes the steps I took along those lines.

First, I followed a set of steps to see if the router was bricked.  I disconnected all ethernet cables and plugged in its power cable, and let it sit that way, powered up but not being used, for at least five minutes.  Next, I connected the router only to the computer that I would be using to examine its condition.  I did not connect it to the modem or to any other computers.  Then I started gathering basic information.

Gathering Basic Information

I went into Control Panel > Network and Sharing Center > Local Area Connection.  In the Local Area Connection Status dialog, I clicked on Details.  (I could have done approximately the same thing in a command ("cmd") box.  To open a command box, I would have gone to the Start button and typed "cmd" into the "Search programs and files" box.  In the command box, I would have typed "ipconfig /all.")

In that Network Connection Details dialog, I saw that I had the IPv4 address assigned by the router.  By default, it was 192.168.1.100.  I also saw that the IPv4 Default Gateway was 192.168.1.1.  As far as my network was concerned, this (192.168.1.1) was the address for my router.  I had not set it that way; this was the default address for this model of router.

I closed the Network Connection Details dialog and clicked on the Properties button, there in the Local Area Connection Status dialog.  In Local Area Connection Properties, I scrolled down and selected Internet Protocol Version 4 (TCP/IPv4).  I clicked on Properties.  There, I saw that the computer was set to "Obtain an IP address automatically."  So I knew that I had not manually instructed the computer to use 192.168.1.100.  That address (192.168.1.100) was appearing in the Network Connection Details dialog (above) because the router was putting it there.

In short, the computer was connected to the router at the router's default address of 192.168.1.1.  The computer was then obtaining its own assigned IP address of 192.168.1.100 from the router.  The computer was set to accept automatically whatever IP address the router assigned.

I could verify that the router was indeed set to assign an IP address of 192.168.1.100.  Indeed, I could change that address, if I had some reason to do so.  I could do this by logging into an internal webpage hosted within the router itself.  The router was my computer's gateway onto the Internet.  As described above, the router's default gateway address was 192.168.1.1.  I could go to that address using an Internet browser (e.g., Internet Explorer, Firefox).  I just had to type those numbers, with nothing else, into the address bar of an Internet browser, and hit Enter.  That would take me to the router's login box.  By default, the username for this model was just left blank, and the password was "admin."  If the username or password were forgotten, a reset would be the likely solution.

In the router's internal webpage, in the Setup > Basic Setup tab, I verified that 192.168.1.100 was the assigned "Starting IP Address."  (Other computers on the network would automatically be given related but not identical numbers.)  I could also have changed the router's Local IP Address at that point, if I had had some reason to do so.

Testing the Router

Now that I had this information, I could proceed.  If I had gotten information different from that provided above, it might have been because the router was not working right, or because I (or someone else) had changed the default settings.

Now I could just verify that the router was definitely in touch with the computer.  I had already done that by logging into the router's internal webpage.  Instead, I could have just typed this into a command box:  "ping 192.168.1.1" (or whatever the router's gateway address was).  If it came back with a set of statements indicating that it had received a reply, then that meant that the ping had gotten a response from the router, so all was good.  This situation could be compared against the alternative by unplugging the ethernet cable leading to the router.  In that case, the "ping 192.168.1.1" command would produce no reply or some kind of error message (e.g., "Destination host unreachable").

Nonresponse from the router could just mean that there was something incorrect about the addresses being used.  It could also mean that the router was bricked.  Another clue would come from the power light on the router.  If it was dimmer than the other front-panel lights, or if it just kept on blinking, that would be another clue that it was bricked.

I did not have these problems.  But I was having problems that seemed to be related, at least partly, to the router.  So I looked for more information on testing it.  I found the so-called "peacock thread" on the DD-WRT website.  Its Note 6 defined a bricked router as follows:

A bricked router is a router that you can no longer communicate with through wireless or wired connections. It will give no response. Just because a router doesn't seem to be fully working, doesn't mean it is bricked. . . . A brick will not respond to pings at all.

By this definition, my router was not bricked.  I could communicate with it.  It was just not fully working.  Note 6 went on to provide further information.  It referred to the TTL values produced when I typed "ping 192.168.1.1" (above).  Mine was TTL=64.  Note 6 said this meant that the operating system firmware on the router was responding.  It sounded like some routers would deliberately start at TTL=100, which was apparently a slower setting more suitable for starting the process of upgrading the firmware, and would then switch to TTL=64.  To ping continuously and see if things changed, the command provided above would get an additional -t.  That is, the command would be "ping -t 192.168.1.1."  Usually, if the firmware was not functioning, there would be no response.  Other possible responses were TTL=1 (apparently the same as TTL=100 for these purposes) and "Destination host unreachable," which Note 6 said could be fixed by making sure the computer and the router were using the same static IP subnet.  There were other possibilities.  Note 6 summarized the situation thus:

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.

Again, it seemed clear, mine was not bricked.  I was not clear what that meant.  It wasn't working, but it also wasn't nonworking.  It was working in the sense that I could get into its operating system, but not in the sense that it would actually function as a router.  It seemed there were hardware and software versions of being bricked.  I decided to upgrade the firmware and see what would happen.

The Hard (30+30+30+10+10) Reset

Since it didn't look like my router was bricked, the next step was to do a hard reset.  They recommended doing this before and after every firmware upgrade.  This began with an effort to verify where the reset button was.  On the Linksys WRT54GL, there was a recessed reset button on the back panel, and there was also a concealed button behind the glowing Cisco Systems logo on the left side of the front panel.  The manual was not clear on this.  The button on the back panel seemed to be definitely a reset button.  The one on the front might have been intended only to clear the SSID and WPA Personal keys.

Following instructions, with the router connected to nothing except its power cord, I pushed the rear-panel Reset button and held it down.  After 30 seconds, still pressing the button, I unplugged the power cord.  After another 30 seconds, still pressing the button, I replugged the power cord.  After another 30 seconds -- a total of 90 seconds -- I stopped pressing the Reset button.  Then began what they should have called the 10+10 part of the procedure:  wait 10 seconds after releasing the Reset button, then disconnect the power cord again and wait another 10 seconds, then replug the power cord.  I did all this.  My power LED was not continuously flashing.  I was ready for the next step.

Debricking the Router

I was visualizing some kind of cold shower or slap across the face -- something, anyway, that would deprogram the router back to normalcy, after which a person would then go ahead and fulfill the societal role of reprogramming with "correct" content.  But at this point, it did not appear that there was any unbricking procedure per se.  You just had to reset the router and then install firmware on it.  I wasn't even sure what difference it would make if it was a brick:  it seemed like a person would go through the same steps regardless, as long as s/he wished to upgrade the firmware.  On this understanding, I passed Go, collected $200, and commenced onward to the upgrade step.

Preparing to Upgrade

DD-WRT offered firmware upgrades specifically designed for Linksys routers.  The DD-WRT firmware options had features that did not seem to be included with the standard Linksys firmware.  Most of these features seemed to be designed for networking freaks, but that obseration probably somewhat reflected my ignorance of what many of them even meant.  A few did pop out at me, though.  I thought it would be at least potentially useful, and might sometimes be important, to have features like bandwidth monitoring, a Connection Warning Notifier, a presumably improved kind of firewall, and perhaps a Samba client, since I had had problems getting Samba up and running previously.  Wikipedia offered a pared-down list of what may have been the most important features.

Guided by the Wikipedia list, and by the advice that I should first upgrade with only the micro or mini versions of DD-WRT, I chose the mini.  It had a few more features.  I double-checked my router version on the DD-WRT hardware database.  It said that versions 1.0 and 1.1 of the WRT54GL were supported.  I went to the hardware-specific page for this router.  I liked the idea of upgrading then again, from the mini to the VoIP, because I used Skype; but when I browsed the list of features, it didn't seem like the VoIP option had a lot of additional stuff to offer over the mini.  (The features mentioned above seemed to be included in the mini.)  So I decided a follow-up upgrade would come later, if at all.

It was a bit tricky to find the download.  It turned out that what I had to do was to use the hardware database, enter WRT54GL, and then double-click on the results list (consisting of just that one item).  It gave me three different versions of the Mini:  generic, or for flashing by TFTP or web.  The hardware-specific page said I should use the generic version if I was installing via web.  The web-based approach looked like it might be easier (i.e., harder to screw up).  I decided to use the web-based approach, so I downloaded the generic version (using computer B, which was not connected to the router, though I could also have connected computer A directly to the modem, bypassing the router, and downloaded it over there, which would have saved me the step of copying it over by USB flash drive).  The hardware-specific page pointed me to a specific build fo DD-WRT, so I also downloaded that.  I wasn't sure if I would use it, though, because I couldn't tell for sure if it was for the web or TFTP approach.  It was also smaller than the generic one I got from the hardware database, making me think maybe the webpage promoting it hadn't been updated for a while.  I used a USB jump drive and copied the upgrade files over to computer A.

For the web-based approach, they warned me to use Internet Explorer, not Firefox, though I noticed that someone said Firefox was fine too.  They also advised making sure I had file sharing and could browse to see other computers on the network.  This was not the case for me.  I was hoping that the router could help me solve problems with my network, as described in other posts.  They further advised making sure the computer's power options would not trigger the screen saver, or worse, during this process.  Having reset the router (above), they advised to reboot the computer and log in to the router (above).  I saw somewhere the advice to disable the Windows firewall, so I did that too (Control Panel > Windows Firewall > Turn Windows Firewall on or off).

There were some further recommended steps.  One was to make sure I had everything I needed before I started, because of course I wouldn't be able to go online with the target computer -- which was one of the reasons why I found it advisable to have at least two computers.  This bit of advice was especially important if, for some reason, a failed upgrade would mean the end of Internet contact from that workspace.  I also had to disable security settings and programs.  This included disabling antivirus (Start > search for Security Essentials > turn off real-time protection > Save changes); disabling Windows Defender real-time protection (approximately the same steps); turning off User Account Control (UAC) (Control Panel > User Accounts > Change UAC settings > Never notify > OK); and turning Local Intranet security all the way down (Control Panel > Internet Options > Security tab). 

As advised, I planned to use a wired (not wireless) connection to the router.  I enabled TFTP as a precaution (Control Panel > Programs and Features > Turn Windows features on or off > TFTP client).  It seemed that I did not have to worry about Compound TCP, which was evidently disabled by default in Windows 7.  I did not have to disable wireless (Control Panel > Network and Sharing Center), since I had not set it up in the first place.

Upgrading the Firmware

Now the game began.  The router was connected only to computer A.  I logged in to it on computer A at 192.168.1.1 (above) and went to Administration > Firmware Upgrade and browsed to the DD-WRT*.bin upgrade file that I had decided to install.  I clicked Upgrade and left the room for a minute or two.  When I came back, it said, "Upgrade is successful."  I clicked Continue.  I then noticed I was supposed to wait five minutes before clicking Continue.  So now I waited.  When the router's WLAN light was on (and I had the impression it came on pretty quickly), the upgrade was said to be complete.  Nonetheless, I waited.  When the minutes were up, I had to enter a username and password.  According to the DD-WRT FAQs, the default username was "root" and the password was "admin."  It seemed that I was safe in clicking the Continue button, because when I did enter the password, I got a warning:

W A R N I N G

Upgrading firmware may take a few minutes.
Do not turn off the power or press the reset button!

This part did take a while, especially because I thought I was supposed to wait there.  Eventually it dawned on me that I should go ahead and click the Upgrade button that was staring at me.  Did we not already do this?  Apparently the concept was that I had last been in the Administration > Firmware Upgrade section, and now, after the upgrade, I had been returned to that same section.  So, sure, I could go ahead and upgrade the firmware again if I wanted, but otherwise we were done.  I was supposed to do another hard (30-30-30-10-10) reset, so I disconnected the ethernet cable from the router and did that. 

There were a few things that I did not need to know, but might have needed under other circumstances.  I did not need to know how to recover from a bad flash.  I did not need to know how to put the router into management mode, so as to ease a command-line installation.  There were tons of other instructions and information, but now that I had gone through it once, I thought that it probably could have been quite a bit quicker and more streamlined than it had been for me.

The Acid Test

On computer A, before going online, I now had to re-enable my security software.  I connected the computer to the router and logged back into the router's internal webpage.  The control panel still had the same basic arrangement as before, though sleeker.  For the moment, I left it at the default settings.  I connected the router to the modem.  I still wasn't able to go online.  Following advice, I went back to the router's webpage and made some changes.  In Setup > Basic Setup, I changed Conection Type to PPPoE.  That gave me an opportunity to enter my AT&T username and password.  I clicked Apply at the bottom of that screen.  After a minute, it had finished applying those changes.  I tried again.  Still no luck.

In short, upgrading the router's firmware did not seem to help computer A go online.  It also did not seem to make any significant difference in helping computer A communicate with computer B.  Both the router and a network switch were able to show the existence of the other computer, but not much beyond that.  Tentatively, it appeared that the uncertain status of my router, going into this project, tended to predict an uncertain outcome.  It was not really bricked, and therefore could not be saved; rather, it was just not working right, for some unknown reason, and all this effort could not change that.