Windows 7: IP Address Conflict: Event Viewer

As described in a previous post, I was trying to resolve an "IP address conflict" error message that would pop up when I connected more than one computer to the NetGear FS605 switch on my home network.  The message, in Windows 7, read like this:

Network Error

Windows has detected an IP address conflict.

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

I had worked through a number of possible solutions that did not work for me.  Then one source suggested going into Control Panel > Administrative Tools > Event Viewer.  I had to wait a minute while it read its various events.  In its Summary of Administrative Events, I saw some events whose Source was Dhcp-Client.  This Summary seemed to indicate that details were contained in the Microsoft-Windows-DHCP Client Events/Admin log.  In the Log Summary panel at the bottom of the screen, I looked for a log with that name.  I found one and double-clicked on it.  It opened up a list of 343 events.  I sorted these by Event ID.  Event ID 1001 provided this General error message:

Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address 0x1C6F6541080C. The following error occurred: 0x79. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server.

Event ID 1002 (which, like others below, occurred multiple times) provided this message on its General tab:

The IP address lease 192.168.1.64 for the Network Card with network address 0x1C6F6541080C has been denied by the DHCP server 192.168.1.254 (The DHCP Server sent a DHCPNACK message).

Event ID 1005 was a Warning rather than an Error.  Its General tab said:

Your computer has detected that the IP address 192.168.1.64 for the Network Card with network address 0x1C6F6541080C is already in use on the network. Your computer will automatically attempt to obtain a different address.

Event ID 50034, an Error message, said:

An error has occurred in initializing the adapter 11. Error Code is 0x1004

Chronologically, about half of the events listed on this log had occurred on this particular morning, though I had only been on the computer for about an hour.  Many of them seemed to be spaced about 10 or 11 seconds apart.  I assumed older items scrolled off.  Event 1001 had not occurred in the past several days.  Event 1002 had occurred only once this morning, first thing, when I started up the computer.  All of the events on this log occurred within the first 15 minutes after I restored the computer from sleep (or possibly hybrid sleep).  Maybe that was when this computer B stopped complaining about an IP address conflict.  An Event 1005 was the last one on the log.  Apparently the computer had succeeded, at that point, in finding a different address.

I looked at the Event Log on computer A.  It went back for weeks, so maybe I was wrong about older events scrolling off.  I had installed Win7 relatively recently on computer B.  The Event Log on computer A had the same Event ID numbers.  It also had some others.  On this particular day, it had Event ID 20, which was too long to reproduce here in full, but which started as follows:

The description for Event ID 20 from source Google Update cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

And it also had Event ID 134 on this day:

NtpClient was unable to set a manual peer to use as a time source because of DNS resolution error on ". NtpClinet will try again in 3473457 minutes and double the reattempt interval thereafter.  The error was: No such host is known. (0x80072AF9)

It also had Event ID 315, which said:

The print spooler failed to share printer Brother MFC-7340 with shared resource name Brother MFC-7340. Error 2114. The printer cannot be used by others on the network.

And it had Event ID 1014, which said this:

Name resolution for the name teredo.ipv6.microsoft.com timed out after none of the configured DNS servers responded.

It also had Event ID 4199:

The system detected an address conflict for IP address 192.168.1.64 with the system having network hardware address 1C-6F-65-41-08-0C.  Network operations on this sytem may be disrupted as a result.

There were some other errors that it had not yet had on this particular day.  There were also some that had occurred on this day, but that I have not reported here, at least not yet, because the ones listed above seemed to give me enough to think about for the time being.  These others were Event IDs 8021, 8032, 43029, and 52236.

I looked at the first items of the day.  (These machines were not all set to hibernate or sleep in the same way, if at all.)  On computer A, the first event (other than 43029, "Display is not active") was an Event 4199.  On the Vista laptop, the first event of the day was a 1005, followed by a 4199.  On the WinXP machine, likewise, it was a 4199.  On computer B, by contrast, the first event was Event 1002, and there were no 4199s.  So Event 4199 seemed like it might describe the problem.  I verified that the IP address being referred to on all three machines reporting a 4199 was 192.168.1.64.  (The network hardware addresses reported by Event 4199 varied from one machine and from one Event 4199 message to another.)  That seemed to suggest that I should just reset the IP address on the other machines manually.  I went into IPv4 properties on computer A and changed it to 192.168.1.65.  But I was still unable to go online.  I went into the laptop and tried 192.168.1.66.  While I was there, I noticed that the option to "Obtain DNS server address automatically" was grayed out, and yet there was nothing typed in the manual alternative, so I referred back to my post about OpenDNS and added numbers there.  This did not make a difference on the laptop.  I rebooted and tried again, just in case it would make a difference.  It didn't.  Now I noticed the same thing about computer A, so I added Google's public DNS numbers there.  Somehow -- possibly because I checked the "Validate settings on exit" option -- I wound up in Windows Network Diagnostics on computer A.  It offered this:

Automatically update your network settings
Windows can detect the correct network settings for you.

I thought, why not? and selected "Apply this fix."  It came back with the announcement that troubleshooting had found that "DHCP is not enabled for 'Local Area Connection.'"  And maybe that was true.  But computer A was still not going online.  I went back and saw that it had wiped out what I had just entered.

I noticed, when I went through the troubleshooter on computer A just a moment earlier, that it had the temporary effect of making computer B unable to go online.  I just happened to be at this blog post, and perhaps Blogger was trying to save at that very moment or something.  Anyway, a moment later, Blogger was able to save again.  I was curious about this, so I went back into Event Viewer, sorted for date and time, and hit F5 to refresh.  But no, there were no more recent items, so apparently whatever had happened had been too brief a blip to register on the log.

I tried typing ipconfig in a command box (Start > type "cmd" > type "ipconfig"), on computer A, to see what IP address I had now.  My change to 192.168.1.65 had stuck.  And yet it could not go online.  How was the 65 address conflicting with the 64 address?  Didn't make sense.  I refreshed Event Viewer on computer A.  (I accidentally refreshed this post instead.  Thanks to Blogger, that scrambled what I had written here, so I had to go back and fix it.  That took maybe 20 minutes.)  The last events in Event Viewer on computer A included a 1005 reporting that 192.168.1.64 was already in use on the network.  But ipconfig on computer A reported an IPv4 Address of 192.168.1.65.  So, OK, maybe no more IP address conflicts?  But computer A was still unable to go online.  I rebooted it.  The situation was the same.  The IP address was definitely 192.168.1.65, and there were no new events in the log (from the past 25 minutes or so), and yet I couldn't browse online.  In the command box, I got results from "ping www.ehow.com" on computer B, but not computer A.

On computer B, I went into Control Panel > Network and Sharing Center > Troubleshoot problems > Internet Connections.  That troubleshooter again offered to change my settings.  Since it didn't work last time, I skipped it this time.  It reported the same "DHCP is not enabled" error as last time.  A search for that error led to comments about routers.  Suddenly it occurred to me:  was 192.168.1.64 the only address that the modem was making available -- was that how this worked?  (Note:  I had since discovered that my modem was actually a combination modem/router.)  Consulting my previous post on the modem's part in this drama, I logged into the modem's internal webpage and looked around.  It said that, on the local network, the modem's IP address was 192.168.1.254, but that wasn't what I wanted to know.  That was where I could log into the modem, as I had just done.  But going in the opposite direction, where would the modem find computer B?  There was a log here, too, and it had a bazillion entries saying things like this:

2011/01/15 8:25:35 GMT - L3 - DHCP: Address 192.168.1.64 declined

The date and time reported there were just a few hours earlier.  So it was listening to computer A; it just didn't like what it was hearing.  On the modem's Statistics tab, I found a section containing "LAN Information."  This section reported that the DHCP address was 192.168.1.64.  So maybe that was the address that the switch was supposed to be using?  And then the switch was supposed to generate new IP addresses that the computers could use?

There was a "Routing Table" that seemed to say my ethernet network was connecting to the modem at 192.168.1.254.  That was the "Modem IP Address."  Further down, I saw a "Devices on LAN" section.  This listed two IP addresses as Active.  These were 192.168.1.64 and 192.168.1.65.  It listed two other addresses as Offline.  I hadn't seen those before.  I didn't know what those were for.  The 192.168.1.64 address looked like it was being associated with computer B -- the computer name it showed was partly familiar to me.

I wondered if this table would change if I changed things on the network.  So I unplugged the ethernet connections from the switch, for all computers except computer B.  Then I hit F5 to refresh the modem's webpage.  The name shown for computer B changed slightly, but otherwise these things seemed to be the same.  So the "Devices on LAN" section seemed to be listing all of the addresses from which computers had ever (or at least recently) tried to access the modem.  To test that, I unplugged computer B and plugged in computer A.  On computer A, I changed TCP/IPv4 Properties to specify an IP address of 192.168.1.66.  Sure enough, now the modem's "Devices on LAN" webpage was reporting a fifth entry, for that IP address.  The "MAC Address" reported for 192.168.1.65, on the modem's statistics page, was the same as reported for 192.168.1.66.  Apparently the MAC address was the "network hardware address" referred to in Event 4199 (above).

The modem's statistics page reported, as I say, a DHCP address of 192.168.1.64, and it reported a device on the LAN -- namely, computer B -- at that same address.  Did this mean that computer B was hogging the only available address of 192.168.1.64?  On computer A, I went back into TCP/IPv4 Properties and changed the IP address to 192.168.1.64.  With only computer A connected to the switch and therefore to the modem, I refreshed the modem's webpage.  Now it reported that 192.168.1.64 and 192.168.1.66 (but not 192.168.1.65) were Active, and the name of the computer at IP address 192.168.1.64 was simply "192.168.1.64."  Three of the five items in the Devices on LAN table had identical MAC addresses -- presumably that of computer A.  (The other two were 191.168.1.107 and 125.)

Unfortunately, computer A was not able to go online at this point, even with no other computers connected to the switch, or even with computer A connected directly to the modem.  I wondered if this was due to an internal conflict, in the sense that it now had these three identities.  I did a search for information related to my Motorola model 2210 modem and found a thread where someone said this:

Only one device can be set up as a dhcp client with the 2210.  All other devices will require a static private IP address.

Well, this was daylight.  Another person explained:

The DHCP server will assign only a single IP address, 192.168.1.64. It will be assigned to the first device which makes a DHCP request. Additional DHCP devices will be declined an IP address.

This raised the question of what would have happened if computer A had been the first one to contact the modem.  (For posterity, my search led to a manual for a Motorola 2220, which was apparently similar to the 2210 but had more features.)  To test that, I unplugged the modem and let it sit.  Meanwhile, I changed TCP/IPv4 properties in computer A to obtain and IP address and DNS server address automatically.  Then I powered up the modem, and after it was back online I viewed its webpage from computer A.  That did it.  Under Devices on LAN, it showed only 192.168.1.64.  And it appeared I was right about the internal conflict:  computer A was now able to go online.

It felt, at this point, like the Event Viewer had introduced me to something resembling an intelligent way to resolve networking problems.  I had miles to go.  But this was starting to make sense.  So now, what would happen if I connected computer B to the switch?  I did that.  Now computer B was reporting an IP address conflict.  Computer A wasn't, at least not yet, and ipconfig there continued to report an IP address of 192.168.1.64, but now computer A was not able to go online in the web browser, though it did successfully ping http://www.ehow.com/.  The modem's webpage, duly refreshed, oddly still reported only one Devices on LAN:  192.168.1.64.  I was not presently clear on the name of the computer it was associating with that IP address, but tentatively it appeared that the computer that first approached the modem after a reset would be the one whose real name (i.e., the name I had assigned to it during Windows installation) would appear in the modem's Devices on LAN list.  (The modem's log, which I had erased with the reset, now reported a bunch of new "DHCP: Address 192.168.1.64 declined" errors.)

I still didn't understand why computer B would still gain dominance in terms of Internet access, when both were connected, even if computer A was the one associated with 192.168.1.64.  Life wasn't as easy for computer B this way -- when it wasn't first to the modem, it seemed to struggle more to get online when both were connected to the switch, but ultimately it was able to do so, displaying webpages after one or two refreshes if not right away.

The modem's webpage, viewed on computer B, was hung at this point -- it wasn't reporting statistics, just sitting there with that Win7 spinning hourglass, telling me that it was thinking about it -- so I ran troubleshooting on computer A.  It said, "'Local Area Connection' doesn't have a valid IP configuration," and it said it had fixed that.  Then I was able to see that computer A remained the only item listed in Devices on LAN.  But computer A (and not computer B) was still reporting an IP address conflict, and still couldn't view webpages.

Following another thread, I checked the modem's webpage for information on its range of available addresses.  But there didn't seem to be one.  Even if I found one, it would presumably make no difference.  The modem was going to work only with 192.168.1.64.  Assigning other static IP addresses would apparently not help.  But why would it be better to let computers acquire their own IP addresses, if 192.168.1.64 was the only one available?

I did a revised search.  This led to a webpage with several suggested steps to resolve DHCP problems.  The webpage said that an IP address conflict was one kind of DHCP problem.  It suggested typing (in a command window) "show ip dhcp conflict:".  I tried that.  The reply was, "'show' is not recognized as an internal or external command, operable program or batch file."  An old thread offered this interesting theory, about a system having a modem like mine:

The modem will only hand out one LAN IP address on the network. So the first device to request an IP will be the one to get it. If another device makes a request for an IP it will be denied and that computer will not have internet access.

Another poster in that thread revised that:

Slight correction, the last device to request an address is the one that gets it. So if you have two devices active at once you will get address stealing from each device as the DHCP leases are renewed.

Neither of these seemed to explain what was actually happening on my system.  Any way I sliced it, computer A was the junior partner.  I tried a revised search and then turned to a missing piece of the puzzle:  how did the switch work?  That was a matter for another post.

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.