Fundamentals
Internet Threats and Security (Part 2) and Network Troubleshooting Strategies
Completion of Internet Threats and Security (Part 1)
Please refer to last week's Session 3 web page for the material we will complete this evening.
Troubleshooting a Bad Internet Connection
Analysis strategy if the operating system analysis does not give an answer:
Test the connection at increasingly more distant points to get an idea of where it fails. Usually that will give you a good idea of what the problem is, and who is responsible for correcting the problem.
Initial analysis strategy using the operating system resources:
Windows - I've found the Windows network troubleshooting aids hard to use and they only occasionally successfully solve the problem. If they don't solve the problem they end up misleading you. I suggest first giving them a try, however. If they don't help or if they just confuse you, it's Windows fault, not yours.
Start - Control Panel - [Network and Internet] - Network and Sharing Center - Troubleshoot problems
Mac - As usual, the Mac OS / X network troubleshooting aids are excellent.
Mac: Apple symbol (upper left corner) - System Preferences - Network - Assist me...
From these screens use the subsequent screens, carefully following their suggestions. Try to read completely and understand as much as you can of what they are saying. If you are lucky they will solve the problem for you. With Windows, you will need to be very, very lucky.
Above is the Network screen if you have a wired Ethernet connection, below is the screen with an Airport connection (Apple's name for Wi-Fi).
1. Check if your computer's TCP/IP software is working inside your operating system.
Open up the Command Line Window (In Windows: Start - All Programs - Accessories - Command Prompt --- In Mac: Finder - Go - Utilities - Terminal)
2. Check if you can get to the nearest router.
Type in ipconfig in Windows. You should get a screen something like this:
In Mac this same information is located on the System Preference - Utilities - Network screen shown above.
Look at the IPv4 (Internet Protocol Version 4) address. If you are at home and the address starts with 192.168... and the Default Gateway also has a 192.168.x.x address (usually 192.168.1.1) you can be reasonably sure that your computer, home network, and router are all working properly. The problem is probably with the connection from the router to your Internet Service Provider.
If you are in a public location the IP address could be any of the nnn.nnn.nnn.nnn addresses.
Make note of the IPv4 address and the Default Gateway (or Router) address.
Just to make sure, in the Command Window, type ping nnn.nnn.nnn.nnn where nnn.nnn.nnn.nnn is your computer's IP address (in Mac: ping -c 6 nnn.nnn.nnn.nnn)
If you get the replies shown above, you can be very sure that your computer is working fine and the problem is in the connection from your computer to the Internet.
If you get error messages, the problem could be that the wired Ethernet cable is disconnected, or your WiFi transmitter is turned off, but most likely is the set-up inside your computer. Go back and use the operating system tools shown above, or get help with your computer's set up.
Now, in the Command Window, type ping nnn.nnn.nnn.nnn where nnn.nnn.nnn.nnn is the Default Gateway IP address also called the Router IP address (in Mac: ping -c 6 nnn.nnn.nnn.nnn)
3. Check if you can get to the Internet.
If you get the replies shown above, you can be very sure that your computer is properly connected to the router as it should be, and the problem is between that router and the Internet.
If you get error messages, the problem will have to be resolved by your Internet Service Provider (ISP). You will need to contact them for help.
To find out if you are getting through your ISP to the Internet, in the Command Window, type exactly this: ping 170.149.168.130 (in Mac: ping -c 6 170.149.168.130) This is the IP address of www.nytimes.com
4. Check if the Domain Name Service (DNS) is working correctly.
If you get the replies shown above, you are definitely reaching the Internet. Make the one last check in Step 4 to make sure the Domain Name Service (DNS) is working correctly.
As in Step 2, if you get error messages, the problem will have to be resolved by your Internet Service Provider. You will need to contact them for help.
Finally, in the Command Window, type exactly this: ping www.nytimes.com (in Mac: ping -c www.nytimes.com)
If you get the replies shown above, your Internet connection is definitely working. You should be able to access the New York Times web page in your browser.
However, if you got a ping reply in Step 3 above, and you are not getting one now in Step 4, your Internet Service Provided (ISP) has turned off your access to the Domain Name Server (DNS). This sometimes happens beyond their control, but it is also a favorite trick of theirs if they want to temporarily turn off your service, usually because of a billing problem. You will have to contact them.
Trace Route (the tracert command)
Finally, just for the fun of it, you can often trace the route from your computer to a website computer using the tracert command.
In the Command Window (or Terminal), type exactly this: tracert www.nytimes.com or any other web site you want. In Mac Terminal it is the same.
This shows each router that your connection goes through to get to its destination.
If you read carefully, you can see that my connection goes to my home router (192.168.1.1) to my Internet Service Provider's (Comcast's) local router (98.222.132.1) to Comcast's main Champaign router (162.151.32.173), to Comcast's Chicago router (68.85.176.9). It then makes a mysterious jump through an unnamed router (66.208.229.126) to Level3.net's Chicago router (4.69.158.234). Level 3 Communications is a major Internet company, and is apparently the New York Time's ISP. Level 3 obviously does not want people to see how the connection gets from Chicago to New York, because it goes through 4 routers in which they have turned off the ping response. However, those 4 routers finally connect to Newark, New Jersey ( 4.69.156.37) and (4.30.129.234), and then to the New York Times web server (170.149.168.130), which is probably located in Newark.
tracert does not always work -- it can be blocked as shown in the above example, but it is interesting when it does.
