Software Diagnostics
If you're reasonably confident that your network hardware is OK but the network still doesn't work, the only thing left is software. Successful Web server connections depend on two components:
Simple network connectivity
Configuration of services (including httpd)
| If you need to. . . | Use |
|---|---|
| find network interface card name | netstat -i |
| find default route | netstat -r |
| test connection between two hosts | ping |
| view or modify network interface settings | ifconfig |
| add or delete routing information | route |
| determine your name resolution method | nslookup |
| look up a specific host name or IP address | nslookup |
Unix/Linux Troubleshooting
Network connectivity includes such things as your IP address and netmask, Ethernet, card configuration, and name resolution.
The first thing to test is network connectivity. Say you're trying to access the Web server on the host named loki. Use the following command to test whether you have simple connectivity:
ping loki
The ping command does nothing besides send out a request to a specified host (or gateway) requesting that that host return an acknowledging packet. If it works, you get output like the following:
PING loki (192.251.100.10): 56 data bytes 64 bytes from 192.251.100.10: icmp_seq=0 tt1=32 time=0.8 ms 64 bytes from 192.251.100.10: icmp_seq=1 tt1=32 time=0.7 ms —- loki ping statistics —- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.7/0.8 ms
If the above version of ping doesn't work, there's something else you can try. Note that in the above example you are trying to contact the host by name. This presumes that your computer knows how to translate a computer name (loki, in the example above) into a numeric IP address. This is not necessarily true[2] and may in fact be your problem.
[2] The process of turning numeric IP addresses into symbolic host names and back again is known as name resolution. Typically this is accomplished either by means of a static hosts file (always /etc/hosts on Unix/Linux machines) or by use of the Domain Name Service (DNS).
To test a connection to a host without relying on name-resolution software, use the host's IP address rather than the name.
ping 192.251.100.10
If pinging by IP address works (as in the above example) but pinging by host name does not, your problem is at least partly with your name-resolution mechanism. A quick-and-dirty fix is to add the host name and IP address to the /etc/hosts file of your local machine.[3] If you're not using DNS, that is all you need to do. If you are using DNS (you can tell by trying the nslookup command), you need to add the machine information to your DNS database and/or troubleshoot your connection to the DNS server.
[3] Host files may also be used on Windows machines. Create a file named hosts in the Windows root directory.
Windows Troubleshooting
The Windows operating system(s) offer a much more limited suite of troubleshooting tools. For troubleshooting Windows network problems, your best bet is to get a command-line interface:
Start . Run . command
which should generate a DOS-esque command-line screen. From there, you can use some of the network troubleshooting tools mentioned in the section on Unix diagnostics. In particular, both ping and telnet should work.
Also of interest is the GUI tool winipcfg, available under some versions of Windows. It will generate a display showing information about your network connection, including IP address, MAC address connection, and connection type.
telnet
The telnet client is surprisingly useful. While it is normally used to set up a nonsecure interactive session between client and server (and thus is more or less archaic), the optional port command-line argument makes it an invaluable diagnostic tool.
For example, the following command line tells telnet to attempt to create a network connection to the server found at 192.168.0.100 on port 80.
telnet 192.168.0.100 80
Why should you care? Well, port 80 is traditionally associated with HTTP traffic. If you can connect on port 80, you know that your network connectivity is fine, and any problem you may be having lies somewhere else. The same principle also applies to secure ports (443/https, 22/ssh, . . .) Better still, telnet is reliably found on almost all operating systems.
Use telnet to confirm or deny the existence of basic network connectivity on any network application that is giving you trouble.