Windows 7, Vista, and XP: Networking Four Computers

I had installed Windows 7 on two computers.  Here, I'll call them computer A and computer B.  Both were connected in a basic wired network by ethernet cable to a router.  The router I was using was a Belkin Connect N150, model no. F7D5301.  I did not then know of the possibility of turning my computer into a WiFi hotspot, but I probably would have gone with the purchase of a router even if I had known of it.

I wanted to make the computers visible to, and able to share files with, one another.  I also had a laptop running Vista and an old Windows XP desktop.  This post describes the steps I took on the software side, after sorting out prior hardware issues.

I started with just computers A and B connected to the router.  I ran a search, but it seemed like most of the webpages that were coming up had to do with troubleshooting.  I wasn't smart enough to get into trouble yet.  But then, as I started looking at some of those sites, I wondered whether possibly the computers were already visible to one another, merely by being connected to the router and not complaining about any IP address conflicts or anything like that.  In Windows Explorer on computer A, I clicked on Network.  I got an error up by the menu bar:

Network discovery and file sharing are turned off.  Network computers and devices are not visible.  Click to change.

So I clicked and selected "Turn on network discovery and file sharing" and chose only the home network (not public) option.  Within about 30 seconds, Windows Explorer on computer A was showing both computers.  Well, that was easy.  So now I ran the router's setup software on the Vista laptop and on the WinXP machine, and then plugged them into the router.  I changed the WinXP machine's name and rebooted it.

Changing that name left an outdated entry for the WinXP machine's previous name in the displays on several computers.  On the WinXP machine, it produced an error message:  "[Oldname] is not accessible.  You might not have permission to use this network resources."  The outdated entry wouldn't go away when I refreshed (F5) the view.  Note that I was still down in the Network section of the Windows Explorer folders pane.  I was not using the Homegroup option up topside.

At this point, a search led to the advice to go into my router's firmware, via its built-in webpage, and look for a way to configure its list of devices.  Apparently that's where the old name was being stored.  Finding that place in my router required me to go into its installed software.  Doing that required me to reinsert the Belkin CD and try to run the router utility from there, because the link that its installation had added on my Start Menu wasn't working.  It looked like the CD was apparently only for simple installation purposes, either reinstall the software or quit.  Eventually I figured out that Belkin expected me to have auto-play running on my CD drive, else it would not show me the option of going into its advanced features option.  So I went into Control Panel > Autoplay.  But there, I saw that Autoplay was already on by default for all devices.  I had only noticed the advanced features option by accident -- I left the CD in the drive when I rebooted the machine after an update of some other software.  Taking another approach, I downloaded an upgrade of the router's software, installed that, and used its Advanced Settings option to get into the router.  Once there, though, I did not see any entry for the old computer.  By this time, though, a couple of hours had passed -- I had been working on something else -- so maybe the router refreshed itself.  Hitting F5 to refresh the Network entries in Windows Explorer showed that they, too, had forgotten that old machine by now.

At this point, the two computers (A and B) running Win7 were showing Network entries for all four computers, plus administrators on computers A and B, plus the router.  The Vista laptop and the WinXP machine were seeing the Win7 computers, but not each other.  Oddly, the router's DHCP client list was showing the names of three computers, but not the Vista laptop.  The Win7 computers were able to go online; the others were not, even after a reboot.  So far, networking in Win7 was looking a lot easier than it had been in Vista or XP.  I wasn't interested in investing a lot of time in this, and I had been thinking of dismantling the XP machine, so probably that would be the solution to part of this networking problem.

To summarize, networking in Windows 7 appeared to be a matter of plugging computers into a router, maybe fiddling with the router's settings or upgrading its software (neither necessary in this case), and turning on network file sharing when that option came up.  Networking problems with Vista were still an unknown.  I had previously been able to just plug the laptop into the router and go online, and had not tried to share files among other computers.  But then I noticed that someone (I) had set the TCP/IPv4 settings on the laptop to something other than automatic.  That took care of it.  The Vista laptop saw everything.  Its eyes were opened.  That solved the problem for the WinXP machine too.

The remaining question:  was I actually able to do anything among these computers?  On computer A, I double-clicked on the icon for computer B.  It said,

\\Computer B is not accessible.  You might not have permission to use this network resource.

I searched on that and, as recommended, went into Control Panel > Network > Change advanced sharing settings > Home or Work (in the Win7 computers).  There, I made sure everything was on except password-protected sharing.  The only change I actually made was to turn off the requirement for a password.  And that did it.  Computer A was now able to see the contents of computer B.  A similar change on the Vista laptop had the same effect.

Now I could see "Users" or "Users Share" folders.  How to get full access to one computer's contents from another?  The first step seemed to be to right-click on a drive or folder, in Windows Explorer, and choose Share with > Advanced sharing > Sharing tab > Advanced sharing > Share this folder.  I did that with one drive on computer A.  I tried to view it on computer B, but I got an error:

Windows cannot access \\ComputerA\SharedFolder
You do not have permission to access file://computera/SharedFolder.  Contact your network administrator to request access.
For more information about permissions, see Windows Help and Support

I clicked on the Help and Support link.  It said this could be because

You haven't created or joined a homegroup
You're not using a homegroup, and the folder or printer you're trying to access has not been shared
Network discovery is turned off
Password-protected sharing is enabled
The computers aren't in the same workgroup
Your computer doesn't have the latest updates for your router

Of these, it was true that I hadn't joined a homegroup; I wanted to see about doing it without, primarily because I had seen a few notes of people having complaints about homegroups.  The folder had been shared.  I had turned on Network Discovery and password-protected sharing.  I had now installed the latest downloads from Belkin for the router.  I tried to access \\ComputerA\SharedFolder from the laptop.  Same error message -- except that, instead of pointing me toward Windows Help and Support, it said this:

No more connections can be made to this remote computer at this time because there are already as many connections as the computer can accept.

That sounded like old-school networking voodoo.  I didn't want to go there.  I just wanted the computers to link up.  I decided to try the homegroup option, since that seemed to be the only option that might help.  I reasoned that Microsoft had probably created the homegroup thing because the non-homegroup approach to networking was such a cluster.  Ah, but then I discovered a possible reason for that last sentence in the Vista error message.  I had set the Advanced Sharing properties > "Limit the number of simultaneous users" option to 2.  I thought that was probably all I would need.  I tried setting it to 20, where it was before.  While I was there, I clicked on the Permissions button and gave Full Control to Everyone.  I closed out of there and took another look in these other computers.  Now I got more error messages.  On computer B, the attempt to look at \\ComputerA\SharedFolder gave the same error as before.  But on the Vista laptop, it produced this error:

Windows cannot access \\ComputerA\SharedFolder
Check the spelling of the name.  Otherwise, there might be a problem with your network.  To try to identify and resolve network problems, click Diagnose.

I did that.  It came back with this:

\\ComputerA\SharedFolder is available but the user account that you are logged on with was denied access.

Well, it was true -- as I discovered, back in the Advanced Sharing properties dialog -- that if I clicked the Caching button, I got a new option that said this:

All files and programs that users open from the shared folder aer automatically available offline

But I decided that meant that files from computer A would be copied to computer B and stored there somewhere, if I looked at them on computer B.  I didn't want that.  I had enough clutter already.  I set the caching to "No files or programs from the shared folder are available offline."  I tried the reciprocal step of setting up a partition on computer B, to see if it would be available on computer A or on the laptop.  No joy.

I came across a webpage that made me think perhaps I hadn't explored the requirement (above) of making sure the computers were all on the same workgroup.  In Control Panel > System > Computer Name on the XP machine, it was just WORKGROUP.  Same thing on the laptop and the Win7 computers.  So that wasn't the explanation.

So, OK, maybe it was time to try homegroups.  On computer A, in Windows Explorer, I went to the Homegroup link at the top of the folders pane.  That opened up an option to join the homegroup that Windows detected already existing.  I did that.  It told me I needed to get the password from Ray on computer B.  That was odd, because I was Ray, and I didn't have any such password.  I also didn't want the homegroup to have a password.  It was just me here.

Upon seeing a page that showed something different from what I was seeing, I decided to back up here.  Before going on to the homegroup option, I noticed that, when I right-clicked on the drive I wanted to share and selected "Share with," I wasn't seeing a list of groups or people.  But, ah, when I clicked on a folder instead of a drive, I did.  Hmm.  But surely it was possible to make a drive visible to other computers?

I did a search and found a thread where people were having exactly the problems I've described here.  At this point, the last post in that thread suggested starting with Start > Run (or just type) fsmgmt.msc.  I did that, on computer A.  I went into Shares and double-clicked the drive I was trying to share.  This gave me pretty much the same stuff as before, except in its Security tab.  There, I selected Users > Edit > Full Control > Apply.  I clicked back and forth a couple of times to make sure it took.  The first time, it didn't.  I okayed out and tried again to access this drive from computer B.  No luck.  But now I wondered what kind of user this was, this person on another computer.  The answer seemed to be that it was an Everyone.  In other words, the groups or users presently listed in that Security tab were Authenticated Users, SYSTEM, Administrators, and Users; and since those all had full permissions and the person (me) trying to access computer A from computer B *still* couldn't get on, apparently I had to be in the Everyone class.  So, as advised, I clicked Edit to add Everyone, and then gave Full Control to Everyone > Apply > OK.  This would have been just as easy to do back in the drive > right-click > Share with > Advanced dialog, actually.  Now that Everyone was allowed to see everything, surely someone on computer B would now be able to see the contents of the shared drive on computer A.  And it worked.  Woo-hoo!  So the missing part here was that I needed to add Everyone in that special place.

It was getting late, and I'd had too much fun for one evening, so I decided not to press the point and work through it with all of the machines.  I had faith that this was approximately the answer at least for letting other computers see what was on a Win7 machine, and that's all I really wanted to achieve here anyway, as I had nothing interesting on the laptop or the WinXP machine.  There were some other interesting networking possibilities I was eager to get on with, as described in some other posts on this blog that I wrote up about the same time as this one.

Windows 7: IP Address Conflict: The Ol' Switcheroo

As described in a previous post, after approximately two centuries of trying to resolve an "IP address" conflict among the computers in my home network, traveling across thousands of miles of Internet highways in search of wisdom, I had happened to notice Event Viewer, and had started to use its error messages to figure out where the problem was.  Information from those messages led me to examine reports from my modem's internal webpage, among other things.  I had finally stumbled across what seemed like traces of a rational approach to troubleshooting network problems:  I would go into Control Panel > Administrative Tools > Event Viewer, would identify the error messages relevant to the network situation, and would try to figure out what they meant.  I was now engaged in that figuring-out process.

The concept seemed to be that my brand of DSL modem had just one DHCP address:  192.168.1.64.  Just one computer would get it.  There was, in theory, a process where the computer coming to the party last would get its turn at the modem.  That was not what was happening on my system, though.  I was seeing that computer B was hogging access to the modem.

Unlike most home networks, I was not using a router.  The reason was that my router had stopped working during these ethernet wars.  I don't know if my network screwed it up, or if it was just taking a break, or what.  I had debricked it, as described in another previous post, and had otherwise played around with, and had given up on it until its replacement arrived in the mail, a week or so hence.

What I was using, instead, was a Netgear FS605 v3 switch.  This was not a wireless device, which was fine; my home network was entirely wired.  I was not clear on the differences between routers and switches, within this context, and that was part of what I wanted to understand now.  But mostly I wondered why the switch was not arbitrating successfully among computers.  I had used this switch for substantial chunks of time, over the last couple of years.  It had not previously had a problem in letting multiple computers share a single incoming ethernet line, such as the single 192.168.1.64 line coming in from the DSL modem.  Was I remembering things wrong?  Or had it, too, somehow gotten fried by all the network action that had seemingly toasted my router?

To explore these mysteries, I ran a search.  This search led to a drawing of a system with a router and another drawing of a system with a switch.  Now I saw what I had been misunderstanding.  Basically, a router could serve as a gateway, while a switch could not.  From the perspective of a home user looking out upon the world, a switch had to be on this side of a gateway.  The gateway could be a computer or a router.  When I had previously used the switch to arbitrate among multiple computers, as I now recalled, I had done so in a university residence setting, where the university itself provided a gateway.  In other words, a switch could be within a network, but it could not mediate between, say, a home local-area network (LAN) and the Internet as a huge wide-area network (WAN).

But couldn't my combination modem/router provide that function?  I searched for insight.  One user reported connecting a cable modem (or combination modem/router) to a switch.  A webpage said, likewise, that a modem could be connected directly to a LAN switch.  Another search led to a discussion suggesting that the problem with a switch might be that the ISP (in my case, AT&T) would allow only one connection to the Internet at a time, whereas my switch was attempting two or more.  I wasn't sure I understood that.  But the matter seemed to be cleared up by a definitive statement:

Routers are also the only one of these three devices [i.e., routers, switches, hubs] that will allow you to share a single IP address among multiple network clients.

On this basis, it appeared that my network problems had been due to (a) a bad router and (b) my mistaken attempt to make a switch function as a router.  The question now was whether the router had been bad indeed.  My computers could still communicate with it, as discussed in previous posts, so the acid test would be to plug in the replacement and see what happened.

So I went out to Wal-Mart and got a Belkin Connect N150, model no. F7D5301 v. 1.  Their setup procedure didn't seem to work quite right, so I called their tech support at 877-736-5771.  Within ten minutes, I was up and running on both machines.  No connect issues.  Time to dump the old router.  I wasn't sure how to test the switch, to see if it was at all still good, so I just shelved it.

Windows 7: IP Address Conflict: What Could It Be?

I was continuing a long, long effort to resolve a home networking problem in Windows 7.  The problem was that, if I connected more than one computer to my Netgear FS605 network switch or my Linksys WRT54GL router, I would get an error message:  "Windows has detected an IP address conflict."  I had really tried a huge number of things -- many confusedly, redundantly, or otherwise chaotically, but nonetheless striving in some ill-formed sense to solve this problem.  The solutions I had tried had worked for others; they just weren't working for me.

At this pint, it occurred to me to take my laptop, router, and switch down the way, and try them on someone else's Internet connection.  But now it was late, so that would have to wait until the next day.  But I did not think that the hardware was the problem.  A router and a switch going bad at the same time, after both had served well?

I noticed, when I tried using Google Chrome to do a search during one of those IP conflict periods (i.e., when I had two computers connected to the switch), that Chrome gave me additional information.  Besides saying "This webpage is not available" and suggesting that I reload, their "More information on this error" link gave me an error message:

Error 105 (net::ERR_NAME_NOT_RESOLVED): The server could not be found.

I did a search on that.  It produced a variety of general and Chrome-specific possible solutions.  One ChromeBoard thread went through many of the issues I had examined here and in the previous post, including changing DNS server to OpenDNS or Google (8.8.8.8 and 8.8.4.4).  It seemed the change was supposed to be made in the router, though, not on the computer, and that was different from what I had tried before.  On the theory that my problem was one that a router could sort out, but a switch could not, I went back into my router (a Linksys WRT54GL), as described in that post.  I saw that the router was set to a PPPoE connection type, which was right for my modem but may have been wrong for the router.  I changed that to DHCP.  I saved and saw that this did not solve the problem.  My next step was to try the DNS advice, but it was not clear where in the router's page I should change those numbers.  The page had both "Router IP" and "Network Address Server Settings (DHCP)" sections with DNS options.  The latter seemed right.  But there were three "static DNS" spaces to fill.  I tried the Google numbers (above) for the first two of the three.  That wasn't the solution.  Pooofont recommended unplugging the computer from the wall power socket for a half-hour.  I tried for 15 minutes.  One thing that became clear, as I perused that long thread, was that there were many problems within this Error 105.  Continuing:  I checked Win7's Start > services.msc > DHCP Client and DNS Client; mine were already started and automatic.  Another new possibility:  flush DNS using "ipconfig /flushdns."  I tried it on two computers, and then connected them to the switch; no joy.

Another possibility occurred to me.  Perhaps I had a virus.  But a virus that would immediately affect WinXP, Vista, and multiple Win7 installations, without showing any other effects, and that was not picked up by Avast, AVG, or Windows Security Essentials, all of which had been running on one of these machines or another during this process?

Around this time, I noticed that something had changed.  I had noticed it before, but now it caught my full attention.  Computer B was no longer experiencing IP conflicts when I plugged the other computers into the switch.  They continued to report such conflicts, but now computer B was OK.  Not only was it not reporting IP address conflicts, but it was now able to go online, even through the switch, when all three other computers (one running Win7, one running Vista, one running Windows XP) were also plugged into the switch and were reporting IP address conflicts.

Somehow, computer B had reached a point of functionality.  What had I (or the computer) done to achieve this?  The solution was presumably not a matter of the router or the switch; it was seemingly something about computer B in particular.  But what?  I tried to trace back through the previous post, to see what I might have been doing when this change occurred.  I had noticed it while talking to the AT&T guy, so it was before that.  But then I had to call it a day.  The system went into hibernation overnight, and when I came back to it the next morning, computer B, too, was reporting an IP conflict and was unable to go online.  Maybe it had something to do with resetting the modem, though I didn't see how.  My thinking now was that the modem could not tell what lay on the other side of the switch.  As far as the modem was concerned, it was handing out just one Internet connection.  It was up to the switch or router to arbitrate among multiple computers.

Following advice, I opened a command window in each computer (Start > Run > cmd -- or, in Win7, Start > type "cmd") and typed "ipconfig" by itself.  This produced several different results.  In computer A (running Win7) and in the Vista laptop, it did not even try to report an IPv4 address.  In computer B, it reported an IPv4 address of 192.168.131.1.  In the Windows XP machine, it reported 192.168.1.64 as the only IP address.  This seemed to suggest computer B and the WinXP machine should not be in conflict.  I unplugged the two others from the switch.  But computer B and the WinXP machine were still unable to go online.  Only when I removed three of the four machines from the switch was the one remaining machine able to connect with the Internet.  This suggested that the IPv4 address was not the issue, or at least not the only issue.

Another possibility recommended in that same thread was to go into Device Manager (a Control Panel item in Vista and Win7; under Control Panel > System > Hardware in WinXP), look under Network Adapter, and uninstall the ethernet and wireless adapters, then scan for changes and let it reinstall them.  I wasn't using wireless, so I assumed that part would be irrelevant to my situation.  The wired part was a Realtek device on both computer B and the WinXP machine.  I made sure both computers were connected to the switch, and then uninstalled the Realtek adapter.  I did not opt to delete the driver software.  Then, in the Action menu item at the top of Control Panel, I ran "Scan for hardware changes" in both computers, one at a time.  The WinXP machine started its Found New Hardware Wizard.  I couldn't get the CD drive to read the motherboard manufacturer's installation CD at that point, so I rebooted the WinXP machine and it reinstalled its wired adapter automatically during reboot, and reported an IP address conflict when it came back up.  But now computer B was not reporting a conflict.  I tried the same approach with computer A. 
It still reported a conflict and was still unable to go online.

One thing that was different about computer B, in the networking department, was that I had installed VMware Workstation there.  This seemed potentially relevant because there were VMware Virtual Ethernet Adapter for VMnet1 and VMnet 8 listed in Device Manager on computer B.  But I had had the IP address conflict problem after installing VMware, so I didn't see how that could make a difference.

At this point, I came across a suggestion to use Win7's Event Viewer.  That discussion continues in a separate post.

Windows 7: IP Address Conflict: Maybe It's the Modem!

I had been wrestling for days with a home networking problem.  The problem was that either of my two computers could go online, by itself, when I would connect it to the DSL modem directly or through a network switch; but when I would plug them both into a network switch or router, neither would go online or connect with each other.  Plugging both in at the same time would quickly produce an error message:

Network Error

Windows has detected an IP address conflict

Another computer on this network has the same IP address as this computer.

Most recently, I had explored the possibility that the problem was with a corrupted Windows 7 installation on computer A.  I had reinstalled Win7 on computer A with a brand-new installation; but as soon as I connected it to the switch, both computers were once again unable to go online.

I didn't want to go through the Win7 setup process again, so I replaced that new installation with one that I had made a day or two after the initial installation.  Eventually, computer A, with this day-old installation, did give me the Network Error message.  Interestingly, though, computer B did not.  It was now able to stay connected, through the switch, while computer A was failing to connect.

I had a laptop, running Vista.  It had been a while since I had tried to connect it to this wired network.  I connected it directly to the modem.  It was able to go online that way.  I connected it to the switch while computer B (but not computer A) was connected.  The laptop reported an IP address conflict.  This suggested that the problem was with computer B.  To test that, I removed computer B from the switch and plugged in computer A and the laptop.  But no, those two had a conflict as well.  Finally, I plugged in the laptop and a Windows XP computer.  Those two had an IP address conflict as well.  So it was not some kind of flaw with Win7.

This brought me back to a problem that I had considered previously.  I had seen, somewhere, an indication that the DSL modem was responsible for assigning IP addresses.  I had followed up on this partway:  I had called AT&T, and they had told me that, as long as a direct connection between the computer and the modem was successful, they could not provide me with any further free assistance.  I had had the option of paying for assistance, and at this point it seemed I should have taken that option, because now I was thinking that the modem was failing to assign IP addresses.  Well, but OK, now that it was diagnosed, I wondered if I could fix it myself.

I had bought this modem from AT&T about two and a half years earlier.  My previous notes on it did not detail the setup process.  I think maybe AT&T took care of that for me.  I had moved to another place; the modem had spent some time on a shelf.  But now it was back.  I looked on the bottom.  Nothing there specified a model number, but I guessed that's what the number 2210-02-1022 was.  It said it was "Style MSTATEA."  Motorola didn't seem to know anything about it.  At first, there didn't seem to be a user's guide, but then I figured out a search that got me somewhere.  The manual that I found said there was a web-based configuration page, which I could find at http://192.168.1.254/.  I went there.  It showed me a basic Connection Information and Modem Information and Local Network screen.  Here, I saw that the modem's model number was 2210-02 and I was using software version 7.7.5r8.

At the left side of that screen, I clicked on Login.  It said, "You are currently connected to the Internet."  I went into Advanced > Connection Configuration.  It asked for the Modem Access Code printed on the bottom of the modem.  Apparently this was secret information, so I decided not to type it in this post.  I entered the code.  Evidently I didn't need the login information I had gotten from the manual.  The manual said the default username was "admin" and the password was something that I created on the spot.  It already had the login information for my AT&T account there.  I remembered that a tech support guy had instructed me to set PPPoE as the protocol; that was still there.  The manual (page 9) said,

Your Modem serves Dynamically-assigned IP addresses by default.  Be sure to configure each computer connected to your Modem to accept a Dynamically-assigned IP address, commonly referred to as DHCP.

The instructions, translated into Win7 terms, essentially had me go into Control Panel > Network and Sharing Center > Change adapter properties > Local Area Connection > Properties > TCP/IPv4 > Properties > Advanced.  There, it looked like DHCP was set already, as the manual said.  Trying something else, I went into the router's Advanced > PPP Location option.  It said, "PPP is on the modem."  I had an alternative:

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.

I tried that.  The router's internal webpage gave me these further instructions:

PPP Location Warning

PRINT OR RECORD THIS INFORMATION NOW

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 192.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.

Modem Restarting

The modem can be used after the power light has been steady green for at least 15 seconds.

That approach might have worked if I had still been using my router, but I wasn't.  I was using a network switch, and it wasn't playing ball.  Apparently switches weren't capable of doing the bridge thing.  I reset the modem (didn't have to connect directly; a switch was apparently like a straightpipe for that purpose).  Now, in the modem's Connection Information screen, I got back an Internet IP Address and Internet Gateway Address after a few seconds.  Now that I had gotten over my panic and saw that I could rescue the situation, I actually read the instructions and saw that I hadn't tried the part about configuring the computer's IP address to be 192.168.1.x.  So I went back and did it all again, and this time I did that part too, back in the same location as above ( Control Panel > Network and Sharing Center > Change adapter properties > Local Area Connection > Properties > TCP/IPv4 > Properties.  There, I replaced the automatic settings with the numbers shown above.  Still didn't work.  Windows Network Diagnostics started up automatically.  After a minute or two, it said it couldn't identify the problem.  So I guessed that maybe I had it right the first time, that I needed a router instead of a switch.  But that didn't make any sense.  I had used this switch with this modem before.

So, alright, the joke was on me.  I had to pay AT&T to make the same switch work with the same modem, where they had worked without a problem before.  In the meantime, while I was on hold, I tried to set the modem back the way I found it, but now I wasn't able to connect.  So that was good.  AT&T would have to help me with that.  I could get some more free service out of them before I had to pay them.  And I did.  The guy was very helpful at getting me back to where I started.  It took an hour.  Then he passed me on to AT&T's paid service (877-831-2880).  The phone there rang and rang.  Evidently AT&T wasn't so eager to take my money.  No canned voice giving me information on what number I had reached, or anything.  But at least no hold while listening to godawful music specially selected to discourage people from calling AT&T free tech support.  After ringing for several minutes, I hung up and tried that number again.  This time I did get a canned voice.  So apparently he put me through to the wrong number.  This, he said, was ConnectCheck.  It allowed me to choose tech support.  It rang and rang.  So maybe he was right after all.  He said they would be there until, oops, maybe the wrong time zone.  Friday night, too late, probably would have to wait until Monday.  AT&T, I love you!

So let us review.  How did the guy get me back to working order?  I think we mostly just did ordinary things.  He had me reboot into Win7's Safe Mode with Networking and see if I could browse.  I could.  So he thought maybe the problem there was with antivirus software.  We didn't pursue that back in Normal Mode, though.  He had me do hard reset on the modem, and then log into the modem's webpage, but I think we just looked at information there.  He really had no idea what a switch was; it took him a while to wrap his head around the concept.  Ultimately, he and his managers concluded that the IP Address Conflict error had to be coming either from a bad switch or from bad drivers.  Did I need drivers for the switch?  It was a Netgear FS605 v3.  Well, there was an installation guide.  A manual!  RTFM!  Fortunateliy, there was no installation process or software.  Just plug it in, which I had done.  So how about his other theory:  a bad switch?  Anything was possible, but what had happened on my system -- recurrently, it would seem -- that would have wiped out, first, my router, and then my switch?  Was AT&T sending out electromagnetic pulses to drum up customers for its paid support line?  I could get a replacement for $25 including tax at Sears, or a few bucks cheaper online if I didn't need it right away.

While I was talking to the guy, I plugged in my Vista laptop again.  It came up with a different error message than before.  In addition to the one about an IP conflict, it gave me an option to "Automatically get new IP settings for the network adapter "Local Area Connection."  It also advised turning off the modem or router and unplugging its power cord and then replugging after 10 seconds.  I tried the automatic solution first.  That immediately disappeared after I tried it.  It offered an option to "Reset the network adapter "Local Area Connection,'" so I tried that next.  That failed too, so I went on to unplug the modem, and simultaneously did likewise with the switch, and then replugged them sequentially, waiting for the modem to show solid green on four out of five lights before replugging the switch.  Most of these were steps that I had tried many times before at this point.  They didn't make any difference.

At this point in the game, pending paid support from AT&T which wouldn't materialize until Monday (this was Friday night), I decided that the modem was not the problem.  But what was?  That question called for a new post in this continuing saga.

Windows 7: IP Address Conflict -- Another Computer Has Same IP Address

(As always, with these long posts where I am working through a veritable cluster of issues, feel free to use Ctrl-F to search for the exact error message that brought you here, if any.  Otherwise, these long posts are provided to stimulate ideas, for those who have no solutions as they work with intractable networking problems.)

*  *  *  *  *

I was installing Windows 7 on two separate computers.  As described in a previous post, I was having problems with networking.  This post picks up the discussion partway through that process, when I received this message:

Network Error

Windows has detected an IP address conflict

Another computer on this network has the same IP address as this computer.

In response to this error, one person suggested just powering off the router and then starting it back up.  I had been doing that and was getting tired of it.  Besides, I felt that we might really be on to something here -- that this was, at least, a possible clue as to my network problems.  Another essentially suggested going into Control Panel > Network and Sharing Center > Change adapter settings > double-click on Local Area Connection > Properties > select Internet Protocol Version 4 (TCP/IPv4) > Properties ... but my settings there were already automatic, as suggested -- and also to make sure, in the router's setup webpage, that DHCP was enabled and no machines were being assigned a static address.  But another disagreed, saying that the IP address should be set manually.

Another said, "This issue is usually caused by resetting a router without resetting all the network connected devices."  And that was possible.  I had not yet tried his suggestion, which was to power down everything on the network, including all computers, network printers, modem, everything; then turn on the modem and wait for a steady data light; then turn on the router and wait two minutes; then turn on the other devices and computers, one at a time.  So I did that.  That did not make the router work.  I tried using a network switch instead, a Netgear FS605.  On the switch, the old Win7 computer worked, but the new one did not.

Another suggestion was to type "ipconfig /release" and then "ipconfig /renew" in a command window on each computer.  I tried that last step.  On computer A, the steps worked.  On computer B, I got this:

Windows IP Configuration

An error occurred while releasing interface Local Area Connection: : An address has not yet been associated with the network endpoint.

I decided to try installing fixed IP addresses on these two computers.  Back in TCP/IPv4 Properties, I changed from "Obtain an IP address automatically" to "Use the following IP address," and I set the values as follows:  IP address = 192.168.1.65, Subnet mask = 255.255.255.0, Default gateway = 192.168.1.254.  The IP address was identical to that from the other computer except the other ended with 64.  The Subnet mask was provided automatically, when I started to fill in the boxes, and the Default gateway was the same as on the other computer.  I also checked "Validate settings upon exit."  When I exited out of that, Windows Network Diagnostics offered to automatically update my network settings, saying, "Windows can detect the correct network settings for you."  I chose, "Apply this fix."  The problem, as it then explained, was that until then, "DHCP is not enabled for Local Area Connection."  That, it said, was now fixed.  But "ipconfig /release" still said no address has yet been associated with the network endpoint.  I tried rebooting.  The problem was still there.  My changed settings were gone; the setting had been returned to "Obtain an IP address automatically."

The situation at this point seemed to be that I had to connect to the network -- that is, I had to have the two computers connected together, through switch or router -- in order to have both computers obtain an IP address; but somehow I had to persuade them to get their IP addresses before the system identified an IP address conflict and thereupon shut down the networking capabilities of the router, the switch, or one of the computers.  I wasn't sure this was quite right, but there seemed to be some kind of lose-lose, reciprocal defeat process going on there.

I decided to look at the error message (above) that I was getting when I tried running "ipconfig /release."  The message said, "An address has not yet been associated with the network endpoint."  A search unfortunately gave me a lot of pages I had already checked, suggesting that I was running out of options here.  I did find a thread that suggested several possibilities.  One was that antivirus or firewall software might be "blocking the machine from picking up DHCP from the router," suggesting that maybe I would need a working router with antivirus software temporarily disabled if I hoped to resolve this problem.  Eventually, I switched from AVG antivirus to Microsoft Security Essentials.

Another suggestion from that thread was to install Tomato or DDwrt firmware in the router, assuming I could get it unbricked or find a replacement, because the Linksys WRT54GL (same as mine) allegedly "has lots of complaints," not working consistently with Windows 7, at least until better firmware was installed.  The concept there was that I would connect the router to one computer, upgrade the firmware, and then connect it to the other computer, and maybe in that way the computers would become so adjusted and sane, in this crazy world, that they would be able to cooperate even if I did later substitute the switch for the router.  In that particular thread, unfortunately, a firmware upgrade did not save the day.  Another possibility was that, if I had Bonjour installed (as part of e.g., iTunes or Adobe CS5), that would cause problems.  But I hadn't installed any such program software at this point.

It seemed that I should be able to do the process with one computer before doing it with the other.  I tried that.  With one computer connected directly to the modem, I took the recommended steps:  type "ipconfig /release" in a command window; manually enter 111.111.111.111 and Tab past the Subnet mask in the TCP/IPv4 Properties; save that; go right back into TCP/IPv4 Properties and switch to "Obtain an IP address automatically"; save that; and then enter "ipconfig /renew."  But when I ran "ipconfig /all" to see what had happened, I saw "Media disconnected."  So maybe the computer was confused.

At this point, I returned to this post after an absence of several days.  I plugged computer B into the network switch.  That worked.  Then I unplugged computer B from the switch and instead plugged in computer A.  After a pause, that worked too.  Now, I plugged them both into the switch.  As above, I got the "IP address conflict" error on computer B.  After a few minutes, I got it on computer A too.

This problem had been lingering for a while, and I was not clear at this point what steps I had tried previously.  Influenced by what may have been a redundant search, I found a thread and a more clearly written webpage that summarized most if not all of the various things that people tried to resolve this problem.

Trying one of those steps, I disconnected computer A from the switch.  Then, going back through those steps, on computer B I found, first, that "ipconfig /release" gave me the "network endpoint" error (above).  At that point, the switch had ceased to work.  Even though computer A was no longer connected to it, computer B was still unable to go online.  I removed the switch from the equation -- that is, I connected computer B directly to the modem -- and tried again.  Now computer B was able to go online.  I tried "ipconfig /release" again.  I got the same "network endpoint" error.  I now realized that this probably meant that it was already released and there was nothing else to release.  So I tried "ipconfig /renew."  Its output gave me only a blank for "Connection-specific DNS Suffix."  Evidently that was OK:  I was able to go online.  I disconnected computer B and connected computer A directly to the modem, tried the same steps, and got the same result.  Now I powered up the switch and connected both computers directly to it.  After a few minutes, computer A again popped up an "IP address conflict" error.

With only computer B connected to the switch, on both machines I tried a command-line approach to set static IP addresses.  The steps here were to type these two commands in a cmd box (Start > type "cmd"):
When I tried that on computer B, I got an error:  "The requested operation requires elevation (Run as administrator)."  A search led to the advice to type this to open the cmd box in administrator mode:  "runas /user:administrator cmd."  This didn't work.  The reason, as I found when I ran that command inside another cmd box, was that "Blank passwords not allowed."  My administrator account had no password.  Trying another approach, I switched to computer A, where I was already logged in as administrator (and therefore would not interrupt or confuse the file-copying process that was underway on computer B), and tried the same commands there.  The second command ("interface ip set ...") returned an error:  "The configured DNS server is incorrect or does not exist."

netsh

interface ip set dns “Local Area Connection” static 192.168.1.1

While it was tempting to investigate the command-line option, I went back to the main webpage and found it easy to agree with the advice that "If you don’t need to use a static IP address, it’s best to simply choose DHCP instead of manually configuring the IP address."  This advice had the virtue of not requiring me to do anything.  Unfortunately, it had the drawback of leaving me where I started.  I tried some other links from the search, but now found that computer A was not connected.  Apparently the netsh command had screwed it up.  I typed "exit" at the netsh prompt and closed the cmd box, but this was not good enough.  So I reopened the cmd box and tried "ipconfig /release" and "ipconfig /renew."  That wasn't the answer.  I still could not go online on computer A.  I could have rebooted it, but I had a file-copying process underway there too.  (I was just setting up these computers.  Data had to be rearranged.)

So, OK, I waited until the file copying process was done on computer B, connected its cable to the switch instead of computer A's, and tried to log in as Administrator over there.  I had not previously done that.  Unfortunately, the Administrator account was invisible.  To see it, I had to find a way to enable it.  One approach to do that was to open an elevated command prompt, which was what I probably needed to do above, but now I had seemingly better instructions.  The approach I took was to start by creating a shortcut to an elevated command prompt:  right-click on the Desktop (the actual desktop, not the link in Windows Explorer) and choose New > Shortcut > type "C:\Windows\System32\cmd.exe" for its location (i.e., the target of the shortcut) and call it "Elevated Command Prompt."  Now I followed the instructions to open the elevated command prompt (via the shortcut) and type "net user administrator /active:yes."  The response:  "System error 5 has occurred.  Access is denied."  A search for that seemed to indicate that my elevated command prompt was not giving me elevation.  Basically, system error 5 just meant access denied.  Someone suggested the old "control userpasswords2" command, but that didn't seem to be functional anymore in Windows 7.  Another approach (for Win7 Pro, Ultimate, and Enterprise) was to go to Start > type "netplwiz" > Advanced tab > Advanced user management > Users > double-click on Administrator > uncheck "Account is disabled" > Apply > OK.  Now Administrator was visible in Control Panel > User Accounts.  I rebooted and went into the Administrator account. 

Now that I was logged in as Administrator, after an intervening lunch and nap, I found that I had no idea why I needed to be an Administrator.  I sure wasn't going to enter that apparently destructive netsh command again.  But upon reviewing the previous paragraph, I saw that I was intending to type "net user administrator /active:yes" at an elevated command prompt. I would have thought that my user account, which User Accounts showed as being an administrator account itself, would have sufficed.  Apparently not.  Surely now, though, as an official Administrator, I would be able to go ahead and enter that net user command.  And indeed I was, and I did.  This time, no System Error 5.  Instead, "the command completed successfully."  Good.  Now what?  I decided to try "ipconfig /all."  This confirmed my recollection that computer B was showing no "Primary Dns Suffix" and no "Connection-specific DNS Suffix."  I tried a search on related terms.  The consensus seemed to be that the blank space was not a problem on a standalone machine.

Back at the lucid instructions webpage, it appeared that I had tried everything.  I wondered if perhaps there was a hardware problem with the switch -- if maybe the computers had screwed up both my router and my switch.  Possibly unbricking the router and doing a firmware upgrade, using just one computer, would make a difference.  I plugged computer B only into the router.  It was still a brick.  A search for unbricking led to a suggestion that I make sure it was actually bricked before I tried to unbrick it.  A recommended solution for this was to go to its internal webpage.  For my Linksys WRT54GL v. 1.1, that was 192.168.1.1, so with computer A being the only thing connected to the router, I typed that address in the address bar in my browser and hit Enter.  The default username was blank; the default password was "admin."  That brought up the internal page.  This was not entirely the behavior of a brick, was it? 

I had previously posted the settings I used in the router.  Those settings were still there.  I was using a wire-only network (i.e., not wireless).  Following the manual for the Linksys WRT54GL router (whose instructions were repeated in brief form on the router's internal webpage), I had to change from DHCP to PPPoE in the router's Setup > Basic Setup tab.  Changing to PPPoE opened up a bunch of other options, including my AT&T username and so forth.  Next, on the Wireless > Basic Wireless Settings tab, I set Wireless Network Mode to Disabled.  I made sure Security > Firewall > Filter Internet NAT Redirection was turned off.  In the Administration > Management tab, I changed the router password, and changed to https, and disabled Wireless Access Web and Remote Management.  UPnP sounded like it was going to make life easier, so I left it enabled.  Finally, I went into the router's Administration > Config Management > Backup > Save to make a backup of the current configuration.  Then I went into Administration > Firmware Upgrade tab.  I browsed to the latest firmware upgrade, which I had previously downloaded, and then clicked Upgrade.

So now I wanted to see if these settings and the firmware upgrade would change anything.  First, I connected computer A directly to the modem.  It still couldn't go online, and by now I had rebooted that computer, so apparently that netsh command had really screwed up something.  I went into Control Panel > Network and Sharing Center > Troubleshoot problems > Internet Connections > Troubleshoot my connection to the Internet.  It said, "Your computer appears to be correctly configured, but the device or resource (primary DNS server) is not responding."  A search on that message turned up very little information other than my own post from a few days earlier.  One post said something about using OpenDNS servers instead of those of the poster's own ISP.  Well, that was interesting.  I should use a non-AT&T server with my AT&T account?  It seems OpenDNS had a free service of some sort.  The concept seemed to be that you could "unbundle" your DNS service from your ISP.  Apparently AT&T was now my primary DNS server.  So I could spend a half-hour on the phone with AT&T, or I could try OpenDNS.  I had a feeling I would probably wind up doing both.  But here I was with OpenDNS, so why not?  I've written that up in a separate post.  It seemed to solve the problem.  If it was the netsh command that was to blame, then it appeared that OpenDNS was somehow able to circumvent it in a way that AT&T wasn't.

Alright.  So computer A was able to go online via direct connection to the modem.  Now, how about through the router?  I connected only computer A to the router, and the router to the modem.  But no.  There was no action here.  I ran Win7's Internet Connections troubleshooter again.  This time, a different error:  "Your broadband modem is experiencing connectivity issues."  I turned off the power for "at least 10 seconds," as the troubleshooter recommended.  Oh, but wait.  I was unplugging the *router.*  They were talking about the *modem.*  The modem was having connectivity issues?  If so, how was I able to use it with computer B to save these words in this blog post?  But let's not argue.  I did what they said, this time doing it to the modem, not the router.  I not only unplugged it, I also went on to "press and quickly release the Reset button" on the modem.  I clicked Next on the troubleshooter, but this gave me an ominous remark:  "The connection between your access point, router, or cable modem and the Internet is broken."  Yikes!  I looked at the modem and, sure enough, a big red light where there should have been a green one.  I disconnected the router from the modem and connected computer B to the modem, and gave the modem another ten-second rest.  But no.  When it came back on, I still had the big evil red one.

See, I knew this was going to come down to another phone call to AT&T somehow.  I knew it.  I felt it in my bones.  So, alright, I called AT&T tech support.  I got their automated guy.  He always sounded a bit exasperated with me, like he was explaining this to an idiot.  Fair enough.  But he ended by telling me that I had to check my connections, reboot, and then call back within 24 hours.  End of conversation.  He was polite enough about it, but still.  I guess I couldn't complain.  Instead of spending a half-hour to get a possibly correct answer, I got no answer almost immediately.  This could be a good deal, where AT&T was concerned.

Well, I got off the phone and finished typing and saving these words on computer B, using the connection where the AT&T automated guy had detected a problem.  (Computer B had been the one that was connected while he and I were chatting.)  Oh, the big red one went away when I did another power cycle.  I probably just hadn't unplugged it for long enough.  I had time to redo it while the automated guy was asking me about who I was and what I wanted.

A while later, when computer A had finished doing something else that made it unavailable for my purposes (I felt like a pest, always wanting something just when these machines were up to their elbows in more important challenges), I rebooted and connected it directly to the modem once again and saw that it was now able to go online without a problem.  I ran the Internet Connections troubleshooter again, just to be sure I wasn't halllucinating.  Sure enough, it detected no problem.  That was unacceptable, of course, but fortunately I knew how to fix the situation.  I connected computer A to the router, and the router to the modem, and gave it another whirl.  Got that message about the modem experiencing connectivity issues.  It occurred to me to disconnect computer A from the router and connect computer B there.  I ran the Internet Connections troubleshooter on computer B.  There, where I had not done the transition to OpenDNS, I got the message about not being able to connect with primary DNS server.  I re-ran this comparison, using the switch instead of the router, one last time.  Here, both computers connected without a problem.

To review:  the first problem seemed to be that I had a nonfunctioning router.  The ability to connect to its internal webpage did not mean that it was functioning for purposes of connecting with the world.  The troubleshooter messages pointing to the modem seemed to be mistaken.  The second problem was that I had an IP address conflict.  This seemed to be something that a functioning router might have fixed.  I had worked through other possible solutions without success, so that seemed like my last hope.  At the same time, I was concerned that possibly the IP address conflict itself had screwed up the router, and my use of the switch had suggested that the router, like the switch, would have no effect on the IP conflict.  I could hope that somehow this problem derived from the AT&T modem, though it was not clear how.  The other thing that had arisen, which may have been a real issue or maybe not, had to do with DNS.  I decided not to install OpenDNS settings on computer B.  Perhaps future experiences would teach me about the difference between AT&T and OpenDNS in that area.

Just in case I hadn't already done so, I did a reset.  I could have done this by holding the reset button for five seconds.  I wasn't sure about the time period -- I had heard a number of different periods of time for pressing reset buttons, by this point -- so instead I went into the router's software at 192.168.1.1 and went to Administration > Factory Defaults > Restore Factory Defaults > Yes > Save Settings. I was pretty sure I had tried this before, but I tried it again now. When that was done, it required me to log into the router again, which meant a blank username and "admin" as password. Then I connected the router to the modem and waited to see if I could go online. I couldn't. I went into Control Panel > Network and Sharing Center > Troubleshoot problems > Internet Connections. The lights on my DSL modem were all green, which was good. But the troubleshooter said, "The conection between your access point, router, or cable modem and the Internet is broken." It asked me to do a modem reset, which I had done previously.

So the action steps at this point seemed to be to debrick the router, to ask AT&T if they had any ideas and, failing that, to some up with some other approach to the IP address conflict.  This seemed like a dismal list of action steps, rather oriented toward failure.  I did call AT&T again, but since I was able to connect the computer directly to the modem and get online that way, they were only able to offer fee-based support with what seemed to be a Linksys router problem.  And I would have gone that route, if I had been convinced that I would get my money's worth.

I ran another search.  Regarding the router, one post arising from this search made me think I should try setting the router to DHCP rather than PPPoE.  I did that.  It did not make a difference.  I switched back to PPPoE and notice, as I had noticed previously, that PPPoE contained a "DHCP Server Enable" option, which was checked.  So probably DHCP made no difference.  Looking at a post from the previous search re: debricking, it seemed that my router was not bricked if I could still contact its web base menu and if its power light was not continuously blinking.  Another webpage took me through a more elaborate set of steps and criteria.  I have explored that whole process of unbricking and updating router firmware in a separate post.  It took hours and yet did not solve the problem.

I had been reluctant to throw money at the problem, especially if there was a risk that the network situation itself had been responsible for damaging the router.  It was suspicious that it had been working so well, during several periods over the past several years, and suddenly fell apart when I introduced Windows 7 networking to my computing world.  It was also suspicious that the problem occurred likewise on the network switch, which had likewise seen several years of service.  Yet there was a difference:  computer B was able to go online through the switch, but not through the router.

These developments suggested a revised set of action steps.  One was to see if a replacement router allowed at least one computer to go online.  Another was to continue to work on the IP address conflict, though I was out of ideas.  A third was to think further about the differences between the two computers, and the possibility that a screwed-up situation on computer A was causing problems for the network as a whole.

The plan emerging from those steps was to buy a replacement router, but to test it on computer B first, and see whether it, like the switch, would allow computer B to go online.  Meanwhile, it appeared increasingly likely that I would have to try reinstalling Windows 7 on computer A, to see if that made a difference.  I would probably wait until I had done that before trying to connect the new router to computer A, just in case the Windows installation itself was somehow confusing or damaging the router.  I hoped that a new Windows installation on computer A would work with the switch and with the old and/or new routers.

That seemed to be something I could test without too much difficulty.  I made an image of the current state of Windows 7 on computer A, in case I wanted to keep it, and then started a new installation on computer A.  The networking impact of a new Windows 7 installation is covered in another post in this blog.

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.