Internet trouble can make you crazy. You’re posting away on Facebook and suddenly your posts don’t post anymore. Or maybe you’re emailing your sister and your email program complains it can’t connect to the server. Or maybe your fancy smartTV won’t connect to Netflix.
Now what?
Of course, you call for help. But whom do you call? And what do you tell the tech support specialist when they answer after you’ve waited on hold for who-knows-how-long?
Here is a quick diagnostic for anyone who suspects overall Internet trouble. Do this first, before you call, and you might save yourself and your telephone support technician hours of frustration.
But a caution – this means getting your hands dirty with technology. If that scares you, get over it, for your own good. None of this is rocket science.
One more caution. None of this works with a smartphone or TV. Some smartphones and TVs have primitive diagnostic tools, but as of late summer, 2017, doing this right still requires a real computer. Or, at minimum, a download into your phone.
This first test takes about 10 seconds. Launch a command line window (how-to details below). Don’t be freaked out that it looks like a 30-year-old step back in time. Inside that window, type this command:
ping www.google.com
and check the results. Here is how it looks from a Windows system when everything works. Macintoshes will behave similarly.
C:\Users\gregs>ping www.google.com Pinging www.google.com [216.58.216.228] with 32 bytes of data: Reply from 216.58.216.228: bytes=32 time=20ms TTL=56 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56 Reply from 216.58.216.228: bytes=32 time=20ms TTL=56 Ping statistics for 216.58.216.228: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 20ms, Maximum = 20ms, Average = 20ms C:\Users\gregs>
Ping sends a data packet to the destination you specify and waits for an echo reply. Just like the old submarine movies, only this is across the Internet. And it’s software, not real sounds. The idea is, ping a popular destination and watch for the reply to come back. Not everyone answers pings, but Google is kind enough to do so. If Google doesn’t reply reliably, then you probably have an overall Internet problem.
Also, watch the milliseconds – in my case above, it’s consistent at 20ms. That’s the round-trip time for the echo request to go out and the echo reply to come back. If your milliseconds bounce around all over the place, you may have a problem – or your Internet connection might just be busy from other family members streaming who-knows-what.
Here’s how to launch a command line window:
In Windows XP, click Start…Run. In Windows 7 and 10, just click the Start button. In the box right next to the Start button, type CMD and press the Enter key. There are other ways to do it, but this is the easiest and it’s universal.
In Windows 8 and 8.1, press the Windows and R keys on your keyboard. The Windows key is on the bottom row of your keyboard, right next to the Alt key, on either side of the space bar. In the box, type “CMD” and press Enter.
If you have a Mac, launch the Terminal, found in /Applications/Utilities/
Next Step
Here is your troubleshooting decision tree.
If your pings show something like this:
C:\Users\gregs>ping www.google.com Ping request could not find host www.google.com. Please check the name and try again. C:\Users\gregs>
then you may have an overall connectivity issue, or maybe just a name translation problem. You need another test to be sure. Since we know one IP Address for Google from above, just try to ping that raw IP Address:
ping 216.58.216.228
and see what it reports. If you see 4 replies and the milliseconds look reasonable, raw connectivity is good and you have a name translation problem. If you see errors, you probably have a raw connectivity problem. Do one more command. My example below is from Windows. For Macintosh, the command will be “traceroute,” spelled out.
racert 216.58.216.228
The tracert command traces the route from you to your destination. It’s kind of like looking at a map to find all the stops on a road trip between Minneapolis and Dallas. Or pick your favorite cities. Here is what it looks like when everything is normal – your hops will be different.
C:\Users\gregs>tracert 216.58.216.228 Tracing route to ord31s22-in-f4.1e100.net [216.58.216.228] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms fw.infrasupport.local [10.10.10.1] 2 <1 ms <1 ms <1 ms 216.160.2.158 3 12 ms 10 ms 11 ms stpl-dsl-gw14.stpl.qwest.net [207.109.2.14] 4 10 ms 11 ms 10 ms stpl-agw1.inet.qwest.net [207.109.3.105] 5 20 ms 19 ms 20 ms cer-edge-17.inet.qwest.net [67.14.8.90] 6 21 ms 20 ms 20 ms 216.111.90.126 7 * * * Request timed out. 8 20 ms 21 ms 20 ms 209.85.249.73 9 20 ms 22 ms 21 ms ord31s22-in-f4.1e100.net [216.58.216.228] Trace complete. C:\Users\gregs>
Notice one of the intermediate hops in-between Google and me did not respond. That’s normal. Sometimes routers on the Internet don’t answer echo requests. You don’t care about that – you care about whether and where the tracert dies, which means where all the rest of the hops report “Request timed out.”
The tracert will max out at 30 hops, but if you’re in a hurry, press the Ctrl and C keys on your keyboard to abort it.
Total time for all this – maybe 60 seconds.
And now you have something to give your tech support specialist when you call for help. If you talk to anyone beyond a brand-new rookie, they’ll appreciate you for taking these basic troubleshooting steps first and may take your problem reports more seriously than otherwise.
Recent Comments