|
Edited on Wed Dec-31-03 12:16 AM by 0rganism
If you're running any reasonable OS, you can pop open a "command prompt" or shell and type the following:
ping localhost
This will check that your TCP/IP protocol is working. Next, check your cable connection by pinging your "gateway" host or your DNS server:
ping my.gatewayhost.com (or whatever it is)
If this one responds with times under 100 ms (or 30 ms, if it's on the same LAN), things are probably working okay from a hardware standpoint. Now ping whatever host you're having trouble with:
ping www.mit.edu
If you get a response like "Destination host unreachable", there's probably a network isolation problem somewhere in the routing cloud. If you get a "time out" response, the problem is generally with the destination host -- it could be overloaded or rebooting or configured not to respond to ICMP packets, you won't know immediately. If you get a response like "unknown host", there is a DNS issue, preventing hosts from associating a name to an IP address. If you know the IP address, try pinging that directly.
ping 18.181.0.31
Another thing you can do is a "traceroute" (or "tracert" in MS command prompt lingo). This is a more complete way of checking how your packets are routed.
traceroute -D www.mit.edu or tracert -d www.mit.edu
This should give you some idea of where routing connections are breaking down (if they are), as it pushes a series of packets along specific paths to reach your destination, one step at a time. It's also somewhat informative of where your stuff is going when you send and receive packets. Try it just for fun, with or without the -d.
(Note: some firewalls don't allow ICMP diagnostic packets, as they can be used for certain types of DDOS attacks, so YMMV)
|