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.

Windows 7 Fails to Detect Other Computer on Network

I was becoming acquainted with Windows 7.  Sometimes, when I booted it up, it would immediately recognize the other computer (running Windows XP) on my home network, and would also recognize the (Linux-based) Synology Network Attached Storage (NAS) device I had connected.  At other times, unfortunately, the Win7 computer would only see itself.  This post describes steps I took to resolve that inconsistency.

I did a search on this problem.  I was inspired to undertake this investigation after I used System Restore to restore an earlier state of the computer.  Those other devices were now not visible in Windows Explorer.  They had been visible just a few minutes earlier.  To my knowledge, I had not done anything that would have made those devices more visible, or less so.

When I searched, I noticed a post in which someone said that Windows 7 was also losing track of drive mapping after it went into sleep mode.  I wondered if that was related.  The previous day, the computer had magically mapped drive D, a network drive on the Synology NAS, without any instruction from me to do so.  The poster said that he was experiencing both of these problems.  That particular thread concluded without an indication of a solution.  One poster said, "Ultimately this is just the nature of the way networking is sometimes."  But it seemed to me that it had never been that way between the XP machine and the NAS, or between the NAS and the Ubuntu setup that I had been using before I got Windows 7.

I wondered if it was somehow an XP problem.  The WinXP machine was currently in touch with the NAS.  Was it possibly barring the Win7 machine from seeing either itself or the NAS?  I rebooted the WinXP machine, but that didn't make a difference on the Win7 machine.

It wasn't a hardware problem, or even a networking problem per se.  Access to the Synology unit was through a web-based program.  On the Win7 computer, I could go into that Synology program and could communicate with the Synology NAS unit.  Synology could see the NAS unit, but Microsoft couldn't.  Apparently whatever was keeping Win7 from seeing the NAS was also keeping it from seeing the WinXP machine.  It was all or nothing:  either Win7 could see them both, or (as at present) it could see neither.

After going online in Internet Explorer and accessing the Synology NAS from the Win7 machine, I rebooted the Win7 machine.  That did not make a difference.  The Win7 machine was still unable to see the others.

In Control Panel > Network and Sharing Center > Troubleshoot problems, I tried the Incoming Connections option and said, "Find this computer on the network."  It came back with this advice:

Reconfigure your network

To prevent problems other computers or devices might have when connecting to your computer, no more than one device should perform network address translation (NAT).

I followed the link into Windows Help and Support, but that wasn't actually too helpful and supportive.  I clicked Next, and the Incoming Connections troubleshooter confirmed, "More than one device is performing network address translation (NAT)."  So, OK, which device?  I clicked "View detailed information" and went into Detection Details.  All I could find there that looked like it might be informative was a Network Diagnostics Log.  Following the links there in the Help dialogs, it seemed that, to open that up, I would have to use ThermaData Logger software.  This software seemed to be almost completely unknown through the vendor, ETI Software, that Win7 pointed me to, but I did find plenty of links for it elsewhere.  I had no idea why Microsoft required me to download a 29MB file from a slow connection just to read a log file.  While I was waiting on that, I found ThermoWorks -- the need for using thermal logging software was another mystery -- and was right on the verge of downloading their ThermaData Software Suite for Windows when I looked back at the Help dialog and decided to try instead downloading ThermaData Studio 1.0.5, which was apparently an entirely different deal.  That turned out to be a 12MB file.  While that was downloading, I went back to the dialog and clicked on the "Other Networking Configuration and Logs" link to open NetworkConfiguration.cab.  That led me to two text files:  ipconfig.all.txt and route.print.txt.  Neither contained any obvious references to NAT.  I installed ThermaData Studio.  Back in the dialog, I tried again on the link to the Network Diagnostics Log.  ThermaData Studio wasn't going to read it right there on the spot, so I downloaded the log and tried opening it from there.  But when I double-clicked on it, I got a message, "Windows can't open this file."  I went into the Start Menu and opened ThermaData Studio from there and tried to use it to view the file that I had downloaded.  At first, it didn't see anything -- it was looking for .msdb files -- but when I told it to look for .etl files, it found the download.  It gave me a completely empty file.  ThermaData Studio looked like solid software, but since I did not need it after all, I uninstalled it.

We were left with the question of which devices on my system were set to NAT.  Trying another approach, I disconnected the WinXP machine from the network and re-ran the Win7 Incoming Connections troubleshooter.  That didn't eliminate the NAT problem.  I reconnected the WinXP machine, disconnected the modem from the router, and ran the troubleshooter again.  Now the NAT problem was gone, though now there was a new problem, where the troubleshooter said it needed more information.  So, OK, possibly the modem plus at least one other device was doing NAT on my network.  I had seen a post indicating that modems and routers can both do NAT, so I plugged everything back where it belonged and looked at the pages on port forwarding and putting a router into bridge mode that that post linked to.  Following what the latter seemed to be saying, I looked at a sticker on the bottom of my modem.  (I didn't seem to have a manual for it, but could probably have downloaded one.)  It gave me an IP address to enter into my Internet browser; and when I went to the appropriate page, it asked me for a code that appeared on that sticker.  This led me into the configuration software for the modem.  After poking around for a minute, I found a page for the modem's PPP location.  This seemed to be what I wanted.  It gave me two options:

PPP is on the modem.  This is the normal mode for this modem.  The PPP session is initiated from the modem.

PPP is on the computer, gateway or router.  This should only be used if you need to run a PPPoE client on your PC or you use another device (e.g., gateway or router) to initiate a PPPoE session.  This is often referred to as "Bridged" mode.

Since option A wasn't working for me, and since the post seemed to be saying that I should use option B, I switched to that and saved the change.  This gave me a Location Warning.  It said,

When using Bridged mode, your access to the modem becomes limited.  To return to the DSL modem user interface after this change you need to directly connect your PC to the modem without any gateway or router between the modem and the PC, and configure your computer appropriately.

Configure the IP address of your computer to be on the same network as the modem by using an IP address of the form 198.168.1.x (except 192.168.1.254) and a network mask of 255.255.255.0.

You may also return to the DSL modem user interface by resetting the modem back to its initial defaults.  All configuration changes and other settings will no longer be available if this is done.  To reset the modem press the "Reset" button located on the back of the modem.

We still had a problem.  The modem was supposed to be restarting, but it wasn't working.  It had three green lights on, including the one for the ethernet (i.e., router).  But why wasn't its Internet light on?  I unplugged its power cord, waited a minute or so, and plugged it back in.  That didn't help.  I tried the same thing with its Internet (i.e., telephone) cord.  When it was unplugged, the modem's DSL light was flashing red.  So I seemed to have a mistaken understanding of the difference between its DSL and Internet lights.  Well, whatever.  It wasn't working, is the point.  I thought that possibly AT&T (my ISP) needed the modem to be in the other mode.  I thought about calling them to ask, but Christ, to enter again into that vale of tears:  no way.

Well, I would have liked to research the modem situation further, but there was just one problem:  I couldn't, as I now had no Internet connection.  I ripped off the sticker on the back of the modem that said, "Remove only if advised by tech support" and there, in all its glory, behold:  the Reset Hole.  I jammed a paper clip into it and watched in amazement as this achieved ... nothing.  It seemed the Reset Hole had gone stale.  It took a couple of tries, and possibly the discovery that this unit required a minimum of 30 seconds of pressure in the hole to achieve the desired reset.  Even so, I could get online only by cabling the computer directly to the modem.  The router seemed to be dysfunctional.  There was, inevitably, a call to AT&T after all, and it actually took only ten minutes

I went back to the modem's webpage, but was now getting "Unable to connect."  Taking plan B, I cabled the WinXP computer directly to the modem, as advised above.  But still, no joy.  No Internet light on the modem; Unable to connect in Firefox.  Now I had really done it.  I had gone and given myself no alternative but to call AT&T.  A half-hour later, we emerged with the discovery that I, in keeping with the spirit of the event, had lost my router password and unfortunately could not go online to figure out how to reset it, given that the reset button seemed to be having no effect no matter how thoroughly I massaged it.  Oh, and the modem was back in its original mode.  End of bridge mode strategy.

I ran a search on this reset problem.  It produced some possibilities.  One was that I needed to reset my TCP/IP preferences to match the router's IP address.  Another was that I just wasn't following the right steps to reset it.  Apparently it was too early to call it a brick; but even if it hadn't been, there seemed to be some kind of de-bricking option.  Or maybe I just needed to go through the full set of steps for setting up the network properly.  The part that I may have left out, in resetting the router, was that I did not disconnect all except the power cable before doing the reset.  So I did that now, and held the reset button down for an overly long time.  I replugged the cable between it and a computer.  In the computer's web browser, I went to 192.168.1.1.  This connected me to the router's webpage.  The password to get in, after resetting, was admin.  Now I set Wireless SSDI Broadcast to Disable.  The webpage said I needed to initiate the push-button setup at this point.  It seemed they were referring to the backlit Cisco Systems logo on the front of the unit; pressing it revealed that it was in fact a button, and this produced a message on the webpage:

Accepting clients!

You will be returned to the previous page after SES configuration completed.

It then did its thing for a couple of minutes, and then I was back at the webpage.  The manual seemed to indicate that WPA2 Personal would provide the best available security for my setup.  I enabled Wireless MAC filtering.  The manual said that the option to Filter Internet NAT Redirection "uses port forwarding to block access to local servers from local networked computers."  That sounded vaguely like what someone had said I needed to make my network work again, so I enabled it.  A search led to the advice that I should not enable these until I needed them.  I disabled Wireless Access Web, in this wired setting.  A few more settings, and then I was done -- and still unable to connect to the router.  The troubleshooter was going to be unable to give me much help, it seemed until I connected the router to the modem, so I did that.  That still wasn't working, so I used the router's webpage Administration > Diagnostic options to ping the local IP address of 192.168.1.1.  That worked, but was I just pinging the router itself?  I tried 192.168.1.100.  That worked too.  I thought maybe the Traceroute diagnostic would be more helpful.  It wasn't.

The manual gave some troubleshooting steps.  Following its guidance, I made sure the router's light was solid green.  The other instructions weren't applicable.  For a moment there, I gave up on life.  Then I ate a piece of chocolate and tried removing that NAT Redirection filter.  That wasn't the solution, but it gave me enough cockeyed optimism to try the Internet Connections troubleshooter.  It -- a veritable font of sharp-eyed discernment -- said this:

Your broadband modem is experiencing connectivity issues.

It said I had better power down the modem, wait 10 seconds until the lights were off, and then power it back up.  I decided to also plug its cable back in.  I was hoping that the troubleshooter would at least say, "Hey, we have found your modem -- so far, so good!" and I guess in a sense they did.  With everything duly de- and re-powered and cabled, I tried it again.  Now, by gum, we had a breakthrough:

Your computer appears to be correctly configured, but the device or resource (primary DNS server) is not responding.

What could this mean?  I had no idea.  I rolled the dice again on the Incoming Connections troubleshooter.  While that was running, I realized that a minor miracle had occurred.  Very quietly, while I was over there fixating on the Win7 computer, the computer on which I was writing this post had connected to the Internet -- through the cable, through the router, through the modem, through thick and thin!  And ... er, no, it hadn't.  Correction on that.

But at least there was a glimmer of hope.  By this point in the day, I had moved away from the Windows XP system, on the second computer:  I had rebooted with an Ubuntu live CD for maintenance purposes, and was therefore  writing this post in Firefox on that machine while it endured its maintenance throes.  And on that machine, for a minute there, I thought maybe it had made Contact.  But it had not.  I was in error.

Well, I had blown a good part of a day on a single troubleshooting problem.  This was, thankfully, a less frequent experience than it had been in years past.  I really and truly hated networking, and it probably showed, by this point, in my failure to grasp some obvious solution or to utilize some true-blue technique.  I really had no clue.  The problem wasn't with the modem or the Internet connection; I could save this post when I connected directly from the modem to this computer.  Possibly the problem wasn't between the Win7 computer and the router; the troubleshooter had felt that everything was in place there.

Trying something a little different, I got an ethernet switch off the shelf and connected both computers directly to the modem through that.  And, whoa, that changed everything instantly.  The Win7 computer popped up a dialog asking me to Set Network Location, and it was immediately connected to CNN.com, and the Ubuntu live CD spun up and updated this text shortly thereafter.  So.  It was the router.  I knew it all along.  What could this mean?  It could mean (a) the router was malfunctioning or (b) I did not have its settings right or (c) the real explanation, which I did not presently know.  Putting my money on (b), I reconnected the Win7 machine to the router, went to its webpage, and chose the Administration > Factory Defaults option.  When it was done wiping out all my hard work, it required the no-username, "admin" password entry.  I ran the Win7 Incoming Connections troubleshooter again.  It said it needed more info.  I tried it again with the modem connected to the router.  (CNN.com was not responding at that point.)  This came back with the message about how the modem was experiencing connectivity issues.

We seemed to have the beginnings of insight.  It appeared that I should have tried the ethernet switch and the factory defaults, right away, as alternatives to my custom configuration of the router.  Experiencing success with one or both of those alternative approaches would have clarified matters.

But that wouldn't be networking -- because, now that I had unplugged and replugged the switch a few times, it was no longer doing the job on either computer.  Everything was connected to it, as before, and the modem's lights looked right, but neither computer was able to connect.  With the switch still connected, I tried rebooting the Win7 computer.  It was no use.  The Win7 machine was still not able to see the world, and the Ubuntu computer was pretending to connect.  I powered down the switch and tried a direct connection from the modem to the Ubuntu computer.  Still crawling.  I powered down the modem for a minute.  That did it:  the Ubuntu machine was now going online without a sweat.  I tried the switch again.  That worked on both machines now.  So apparently the switch did get confused and need some time off.

The conclusion seemed to be that, if I needed a router, I needed to try a new one, and otherwise I should just use the switch and power it down for a while if it failed to work.

Both computers were now going online successfully.  What did the Win7 troubleshooters have to say about this?  The Internet Connection troubleshooter said that it "couldn't identify the problem."  This was apparently tactful speech:  it seemed to mean that it couldn't identify *a* problem, but didn't want to tell the user that s/he was imagining things.  The Incoming Connections troubleshooter said this:

Troubleshooting was unable to automatically fix all of the issues found.  You can find more details below.

Problems Found

Windows requires more information to diagnose the problem.

Here, too, there seemed to be a bit of a bullshit factor.  I had been taking these troubleshooters as though they meant exactly what they said -- that, in the latter case, there was a problem, though it was difficult to diagnose -- but now it began to seem that they might say this when there wasn't necessarily a problem.  Pointing me to an online source of the "more information" that the program needed was a funny gesture when, according to the troubleshooter itself, I might not be able to go online.  It seemed pretty lame, worthy of Windows 95.  After all, this was Microsoft's software reporting on Microsoft's software.

What remained, it seemed, was to choose between the switch and a new router.  That was a question for another post.

Ubuntu and Router Continued

I had been working on getting VMware or some other virtualization product to let me run Windows XP on top of an Ubuntu Linux system, when I ran into problems with my router. This post describes the steps I took in getting a connection going again, before returning to that main discussion. There is also a previous post on how I got the router going in the first place. The router in question was a Linksys WRT54GL Wireless-G 2.4GHz 54Mbps broadband router. In hopes of getting it going, I consulted its manual, a PDF on its installation CD. It explained that the button I had accidentally punched, on the front of the router, had something to do with the router's SecureEasySetup function. It said the light would stop flashing when the router had finished generating its SSID and WPA Personal Key. It was not clear, from the manual, what I should do in this case. I tried punching the button again. At first, it did nothing, but when I punched it and held it for a second or so, it started flashing white. This continued for several minutes. When it was done, I tried again to load a page in Firefox on the secondary computer. This failed. I connected the secondary computer directly to the modem, bypassing the router, and tried again. The webpage I had been trying to reach came up almost immediately. Likewise for another. The problem, at least for the secondary computer, was the router. I installed a months-old copy of Symantec AntiVirus on the WinXP installation on the primary machine, for what it was worth, and tried the same trick with it, connecting it directly to the modem. It did not work. I rebooted that machine into Ubuntu and tried connecting there. Its webpages, too, loaded fine when the machine was directly connected to the modem, but not when it was connected to the router. So for both computers, the router was the problem. But what was the solution? I guessed that I might have reset the router when I picked it up and inadvertently punched that button. I noticed that I was able to get as far as the password screen when I typed 192.168.1.1 into Firefox's address bar and hit Enter, but I just got an error message when I typed 192.168.1.2 or 192.168.1.100. But System > Administration > Network Tools > Devices > Network Device > Ethernet interface (eth0) was reporting an IP address of 192.168.1.100. I dimly recalled that I had configured it to something other than 192.168.1.1 (which, according to p. 22 of the Linksys manual, was the default) when I was setting it up. So now, using the default username (leave it blank) and password (admin) specified in the manual, I was able to log into the router at 192.168.1.1. My logic was challenged, however, because when I tried to change the 1 to 100 in the router's internal webpage, I got an error message saying, "Starting IP address can't be LAN address." I went to Administration > Status, there in the router, and saw that I was running firmware version 4.30.11, dated August 7, 2007. It was a year old. Also, it stated that its IP address was 192.168.1.64, and that the default gateway was 192.168.1.254. I had no idea what to do with this information. I plugged the primary computer into the modem directly. I was going to do an online chat with Linksys tech support, but that required the Java Runtime Environment. I had not yet installed that, and was not sure how -- it was more difficult in Ubuntu than in Windows, where I would just click on an icon. So instead I went through their Ask Linksys option. The first step, they said, was pinging. I had to translate somewhat -- their instructions were for Windows, and I was now trying this on Ubuntu. Basically, I used Ubuntu's Network Tools > Ping for www.linksys.com and got an indication that that address could not be found. I then used Ping for 192.168.1.1 (the router) and got 100% success. I plugged both computers back into the router and, on the secondary computer, went back to the router's webpage. Following instructions, I clicked on Wireless > Basic Wireless Settings and changed my network name to something unique. I went to the Wireless Security tab and set it up, which I had not done on the secondary computer because I had just been using a wired connection. One of the Linksys webpages, which I had left open, told me that the 192.168.1.100 visible in Network Tools was the computer's IP address. Another said that 192.168.1.1 was the default gateway. I was at a loss. I ate and sat and thought. I booted the main computer back into Windows to try Linksys EasyLink Home Networking. That was silly; I had forgotten that the main computer couldn't go online at all, not as long as it was plugged into the router. I tried ping and ipconfig in a Windows DOS box. Pinging the router got zero success. Entering 192.168.1.1 into the Internet Explorer address line yielded an error. It seemed that the Windows setup had problems beyond just the router. I went back to the secondary computer, where at least I had contact with the router. I finally did find a Linksys tech support page that seemed on target. I followed its advice to change the router's local IP address to 192.168.2.1. Now I was not able to contact the router at all. It was a brick. I bought another router. This was a Linksys WRT54GS. I noticed that one of the sheets accompanying it had an 800 number for tech support. I hadn't been able to find one on the Linksys webpage, else I would have used it. But now we were in a new chapter. I ran the new router's installation CD in a Windows XP boot on the primary computer. This wasn't a Linux-based router, and maybe that's why its installation procedure was somewhat different. This one promptly advised me that it didn't find an active network adapter on the primary computer, and that reminded me -- gee, I haven't installed the motherboard drivers in this basic Windows installation yet. VMware and VirtualBox hadn't seemed to need them. Installing them had sometimes been frustrating and time-consuming in the past. How about if I tried setting up the router in Linux first? I rebooted into Ubuntu and meanwhile looked up some advice. As advised, I went into System > Administration > Network > Connections, unlocked, and changed the Properties of the wired connection to DHCP, and plugged in the router. That proved to be incorrect; it was better left on the Automatic setting, not specifying DHCP. I got the router's internal webpage and followed a Linksys instruction to change the local IP address to 192.168.2.1. The internal webpage confirmed that this change was successful, but was then unable to go any further, and eventually gave me an "Unable to connect" error. As I reviewed the Linksys instructions for Windows, I thought the problem might be that I had failed to release and renew my IP address. The consensus on that seemed to be that I should enter these lines:

sudo ifdown eth0 sudo ifup eth0

possibly followed by "/etc/init.d/networking restart"; but the first of those lines got me "interface eth0 not configured" and the second one returned "Ignoring unknown interface eth0=eth0." I did not get those error messages, however, when I tried a different version:

sudo ifconfig eth0 down sudo ifconfig eth0 up

However, I was still able to ping 192.168.2.1 with 100% success. Plainly, I did not know what I was doing; just as plainly, though, I was not successful, so far, in finding the right sources of information. Surely those sources were out there; they just weren't coming up in my Google searches. What I was getting, instead, was a lot of confused people and, time after time, bits of advice that were partly helpful, that worked for some people and not for others, from which I could hope for tiny steps of forward progress. I had hesitated to call the Linksys tech support number because I doubted they would know anything about Linux. There had been no mention of Linux in the Linksys materials I had reviewed so far. As I recalled, they had previously told me that tech support for Linux was not free. My impression was that fee rates for tech support were pretty high. It then occurred to me that I may have confused the router by repeatedly unplugging and replugging the Ethernet cable. I was sharing one DSL connection between two computers, using one to write these words and research the issues, and then plugging in the other one to test the next idea or suggestion. This did not seem likely; all of the correct lights were on when I did plug in the router. But I rebooted the primary computer anyway, just in case. Sadly, that did not help. I tried contacting the router at 192.168.2.1 on the secondary computer. That too was unsucessful, as were attempts at 192.168.1.1 and 192.168.1.100. Lights on the router were flashing, but all I was getting was "Unable to connect." On a good night's sleep, I felt refreshed and ready to approach this issue again. First, I would try the advice that someone had given, in response to my question posted on the Ubuntu Networking & Wireless forum:

there is really no need to go to 192.168.2.1 unless you have some weird network. Anyways try reseting it to defaults so you can get back into the configuration screen. Hold the reset button in for 15 seconds or so. I actually pull the power out while holding it and plug it back in while I am still holding it down. That should clear out any problems in the router.

The person offering this advice had posted more than 1,000 times in the Ubuntu forums, it said, so I had to think s/he was reliable. I did it exactly as s/he advised, having discovered in the meantime that the reset button was actually on the back of this new router, and the function of the button on front was apparently somewhat different. This procedure did enable me to contact the router at 192.168.1.1 in Ubuntu on both machines. As with the previous router, I was able to ping the router (192.168.1.1) successfully from both computers. In the router's webpage, I changed the network name and set up wireless security. But I still had no connection. I called Linksys Tech Support (800-326-7114) and went through their automated help guide. They had only Windows and Mac options, so I chose Windows. The guide proceeded at a very patient pace. I hate to say it, but it was better than speaking with a human, because I was able to take notes, repeat steps multiple times if it took that long for me to make sure I got them right, etc. The guide took me through the steps of powering down the modem, router, and computer, and then powering them back up, one by one, waiting until the Internet light was solid on the modem and the power light was solid on the router before plugging in or turning on the next item. When the computer came back up in Ubuntu, I started Firefox. They had me go to 192.168.1.1 again. There, I checked for Status > IP Address. Mine began with 192.168. In that case, they wanted me to go to Setup > Basic Setup > Local IP Address and change it to 192.168.2.1, then Save Settings. I did that. This gave me a new message: "Settings are successful. Please release/renew IP." They didn't have me do anything to release/renew except just restart the computer. The other nice thing about the automated phone guide was that, of course, I didn't have to remain online to keep getting instructions when, as now, I was rebooting (if I'd had only one computer). Anyway, these instructions didn't do the job. I still wasn't able to go online on the primary computer, so I had to speak with a technician. While I was waiting for him, I made sure both computers were plugged into the router, and I tried going online with the secondary computer. Unlike the first one, it was working through the router now. The technician, as it turned out, would not help me with Linux -- he said they did not support it. I told him I had a Windows dual boot. In that case, he referred me to his senior technician. He was going to transfer me to that senior technician, but the call was disconnected when he attempted to transfer. I had a case number, and I left it at that for the moment. I posted a reply on the discussion thread I had started in the forum, and meanwhile I rebooted the primary computer into Windows XP. I made a System Restore backup point and proceeded to install drivers for all items with yellow exclamation mark circles in Control Panel > System > Hardware > Device Manager. This resulted in the first instance when Windows failed to start up. I hit the reset button and tried again. Windows booted and everything was good, including its connection to the Internet through the router. I rebooted into Ubuntu again. Now the Internet connection worked there too. Very strange. I disconnected that Linksys WRT54GS router and reconnected the Linksys WRT54GL, which had now sat on a table for about 24 hours. It, too, was now working fine. Very strange! The factors that contributed to a solution on this issue, I think, were the reset procedure and/or letting the router sit, which someone had said was helpful; going to the Linksys tech support 800 number, and especially the automated procedure, which I had not used previously; and perhaps getting some distance from the problem, which had reached the point of frustration and counterproductive redundancy on the previous evening.