Last week, my wife told me the Internet was running slowly, so of course I checked the Ookla Speed Test page to see what was what. When speeds in the usual range manifested, I assumed the problem was a hiccup and nothing more. I was wrong, but it took me quite some time to figure out why. As it turns out, we tend to visit the same sites repeatedly at my house, and do very little serious random surfing. This matters for an interesting reason, but more on that shortly…
Yesterday morning I attempted to remote to one of my Windows 10 test units, and was mildly miffed to see it wasn’t working. Wanting to grab a screen shot of the Insider Hub, I simply attempted to connect to the other test unit, only to fail yet again. I checked the Remote Settings in the System widget in Control Panel, and found no problems. I check homegroup status, and quickly realized there were also issues there. Then I tried to connect via the usual IP address for one of my test units, and it failed, too. Very interesting!
My next step was to sit down at that same test unit, fire up the command line, and run the ipconfig command. Lo and behold, instead of a private IP address in the 192.168.0 Class C range, I saw a 169.254.0.x address instead. This is a special IP address on Windows machines that comes from its Automatic Private IP Addressing (APIPA) capability. Such addresses only appear on a Windows machine when it can’t find a DHCP server at boot-up. This clued me into an issue with my Time Warner boundary device where not only was DHCP not functioning as it should have been, but also where the Domain Name Servers to which the DHCP Server points were also not available (or only intermittently available, because name resolution would occasionally happen on devices with still-working IP addresses, but only very slooooooowly).
Before the TW folks reset their back end server settings, the old DNS server addresses were on a 70.x.x.x Class A network.
I tried resetting my Arris device, and it helped with DHCP (my wireless nodes now had legit LAN addresses) but it still didn’t resolve the DNS problem. A quick phone call to Time Warner led to a call back from their third-level support desk, which informed me that they had changed the addresses for the domain servers on their backbone, but it hadn’t propagated successfully to the broadcast domain for the local cable segment for my neighborhood for whatever reason. After they made sure those values were correct, and another reset to the Arris box, all was copascetic once again.
I concluded my adventures by apologizing to my wife for not properly researching her Internet problem last Friday. Had I done so then, I could not only have taken care of her issues right away, I would also have saved myself the time needed to diagnose yesterday’s strange case of the malfunctioning remote access that helped me find the problem by guess and by gosh. Live and learn, eh?