I’ve been fighting a home networking problem for a couple months. The symptoms were strange, though, and the solution was even stranger…
First, let’s consider the network. I’ve got a Cisco-Linksys wireless B/G/N router with four Gigabit Ethernet ports on it. I’ve also have a couple Cisco SD2008T 8 Port Desktop 10/100/100 Gigabit switches, but they don’t have anything to do with the problem. The problem connections were between wired computer connections and also between wired and wireless computer connections.
I spent a lot of time thinking that the problem was firewall-related, and tried setting numerous firewall exceptions on the computers at both ends.
I also spent time comparing which Windows services were working on the various computers.
Windows File and Printer Sharing worked perfectly. No problems, there. The problems were in utility-type programs.
UltraVNC Viewer, which I use for remote control between the computers, couldn’t make a connection to the UltraVNC Server on the other computer. Unfortunately, it gave no hint of what was wrong. Ping.exe, which comes with Windows, didn’t work because it couldn’t make a connection to the other computer. Ping kept trying to find the requested computer, but at a strange IP address 188.8.131.52. That one definitely was not on my network.
I finally realized that, no matter which computer I was working on, ANY request for an unknown computer or URL was being routed to 184.108.40.206.
I tried to find some setting in Windows that was rerouting my connections to 220.127.116.11, but I didn’t find anything.
I did some Google searching for
Windows 7 name resolution not working
and found a lot of information in Chapter 7 – Host Name Resolution at technet.microsoft.com/en-us/library/bb727005.aspx ; unfortunately, that didn’t provide any help either.
I tried a "whois 18.104.22.168" in Google and found that it was a Cox.net site in Princeton, NJ, but little else. Trying to go to it in Firefox resulted in nothing — no webserver responded.
Finally, I did a Google search for the IP address itself. That gave me a link to some posts in the DSLreports forum — and the answer.
Cox.net, who is my Internet Service Provider, has long redirected to 22.214.171.124 any DNS request for a URL that it couldn’t find. For web browsers, this can make SOME sense, although many people don’t like having their mistypings drop to a "click here to make Cox some money" ad page.
But, if the DNS request is not for a web browser, this is ultimate rudeness as it stops the application until it times out for lack of response — as far as the ping or UltraVNC application is concerned, Cox has told the program that it’s legitimate target is at 126.96.36.199 – and then 188.8.131.52 doesn’t respond.
Using ping from multiple computers, I confirmed that the destination was always 184.108.40.206 for any non-existant domain name (e.g., if it was misspelled) or for any of the computer names in my local Windows workgroup.
This IP hijacking is not appropriate.
Fortunately, one of the messages in the forum also pointed to the solution to my home networking problem.
It all keyed to one of the configuration fields in my router.
One field on the Setup page of the router asked for a host name for the router, so I gave it one.
Another field asked for the domain name. I input my workgroup name into this field — that was the problem that exposed me to Cox’s IP hijacking.
When the Cisco-Linksys router has a name in the domain name field on its Setup screen, it will apply that domain name to any hostname (creating a URL of hostname.domainname) and then send that to the upstream Internet Service Provider.
Since my hostname.domainname referred to my workgroup name and wasn’t a registered Domain Name, Cox.net didn’t find it, so it hijacked the request, returned the IP address of its advertising site to my program, and my program didn’t work.
The solution was almost simple. I had to delete the domain name from the Domain Name field on the Setup page of my router.
The only kicker was that the solution was not instantly available. At that point, the problems still occurred. Rebooting didn’t solve it, either. After a few hours, though, the DNS caches in Windows and/or the router had a chance to flush themselves.
By the next morning, all was right with the world.
So, what did we learn?
- When something doesn’t work, try some Google searches
- describe the error in the search box
- try any other pertinent piece of data in the search box
- sometimes the fixes work immediately
- sometimes the fixes don’t work immediately and need to flush through the system
- if all else fails, sleep on it <grin>