TCP/IP Troubleshooting: Windows vs. Linux With the widespread use of the Internet, the Transmission Control Protocol/Internet Protocol (TCP/IP) has become very important. Any system having problems with connectivity causes issues for any user. For most people with a background in Windows, this article provides a way to learn how to perform the same type of commands you would on a Windows system to that of a Linux system. The first thing to go over are the basic steps of troubleshooting connection problems: Check if your IP address, subnet mask, and default gateway are correct Ping 127.0.0.1 to see if your network adapter is working Ping your own computer's IP address Ping the IP address of another computer on the same subnet Ping your default gateway (local side) Ping the IP address of a computer on a different subnet To do these things, I will cover them for the commands of both Operating Systems (OS). STEP 1 This step requires listing the IP address, subnet mask and gateway for the system. In Windows, the command 'ipconfig' would be used. For Linux, the command 'ifconfig' is used from a Terminal and a sample output is shown in Figure 1. FIGURE 1 Here you can see that I have an Ethernet (eth0) device which is not being used since there isn't a TCP/IP address, subnet mask or gateway assigned to it. The second section is for the loopback (lo) which is assigned the address 127.0.0.1. The third network device is a Wireless Local Area Network (wlan) device. The wireless device is assigned the following: IP Address: 10.0.0.151 Broadcast Address: 10.255.255.255 Subnet Mask: 255.0.0.0 TCP/IP v6 Address: fe80::7ae4:ff:fe5b:11fc/64 Hardware Address (MAC): 78:e4:00:5b:11:fc and other information... NOTE: One major item here is the Rx (receive) and Tx (transmit). These show the number of packets received or sent by the wireless adapter. If these numbers were zero, then it shows a definite issue. As long as the IP Address and subnet mask are valid for your network, then the IP Address should be fine. If any values are all zeros, then there is a problem. If the addresses are assigned by DHCP, then it may be best to reboot or reset the NIC to get a new address. If the address is manually set, then a new address should be configured. On Windows, to release the IP Address and get a new one, you use the following commands: ipconfig /release ipconfig /renew For Linux, you can perform the following: sudo dhclient -r sudo dhclient INTERFACE NOTE: The INTERFACE in my case is 'wlan0'. To manually configure an address, edit one of these locations depending on your Linux type: RHEL: /etc/sysconfig/network-scripts/ifcfg-eth0 Debian: /etc/network/interfaces NOTE: The device 'ifcfg-eth0' may need to be changed to your device number and type, such as wlan0. Another important item to find is the Default Gateway. The Gateway Address is the address to which packets are sent that are meant for a location not on the Local Area Network (LAN). A good example of when the Gateway is needed is when the packets are sent to the Internet. To find the Default Gateway Address, use the following command in a Terminal: route -n The output is shown in Figure 2 and is distinguishable by the Destination Address of 0.0.0.0. You can see from Figure 2 that the Gateway is specified as 10.0.0.57. If the Gateway Address is not correct, this means that the system cannot reach any network other than the LAN. FIGURE 2 If the Gateway Address is incorrect, it can be changed with the following command: route add default gw ADDRESS INTERFACE For instance, if I needed my Gateway on WLAN0 to be 10.0.0.101, I would use the following command: route add default gw 10.0.0.101 wlan0 For Windows, I would enter the network configuration, set it to not be DHCP and enter my addresses for IP, Subnet and Gateway. Step 2 The loopback is a virtual connection to the NIC itself. If you can communicate through the address 127.0.0.1, then the NIC is receiving and sending packets. If no response is made from loopback, the device is disabled or not working. The 'ping' command is a utility which sends an ICMP echo request to a specified address. When the destination system receives the request, it sends an ICMP response to the sender. The time is measured between the packet being sent and a response received. It is best with the 'ping' command to use the count parameter as shown in Figure 3. FIGURE 3 The ping command syntax is to specify the IP Address, in this case the loopback address of 127.0.0.1. NOTE: It is best to specify the -c with a number of pings to try. I used '5' and if -c is not specified, the utility will ping the address until the user presses CTRL+Z or closes the Terminal. Windows PING command performs four ICMP echoes to the Target. If the loopback fails, this shows the device is disabled or malfunctioned. Enable the device if it is disabled. Replace the NIC if needed to test further. If possible, use a NIC from a system that is known to work. If the new NIC works fine, then the problem is most likely a malfunctioned NIC. STEP 3 Now that we have determined that TCP/IP is set up correctly and that the device is functioning properly, we can perform one more test to validate the functionality of the NIC and the TCP/IP protocol locally. We ping the TCP/IP address of the NIC to test this ability. NOTE: Be sure to use the count option with 'ping'. The loopback address is internal to the NIC while the IP Address of the NIC on the LAN can be used to test the outer connector and connection to the LAN. You can think of the loopback as the inner portion of the NIC and the IP Address as the outer portion of the NIC. If the ping works, you can go on to Step 4; if not, there is an issue with the NIC itself or the driver. Remove the Network device. Reboot the system to be sure that everything is completely reset: hardware addresses, memory addresses, drivers, etc. Reinstall the Network Device and the most up to date drivers, which are the kernel itself. Repeat Step 3 or possibly Steps 1 to 3. If it fails again, try a different Network device. STEP 4 Now, we have tested everything local to the system. The next step is to ping a system on the LAN, preferably a server, but not necessarily needed. Find the IP Address of a server or another system and ping it's address to test for connectivity on the LAN. For example, assume I had a server which has an IP Address of 10.0.0.1. I would then use the following command in a Terminal: ping -c 5 10.0.0.101 If I get a response, then all is well so far; I can then go to Step 5. If the ping fails, then there may be an issue with connection to the hub. For a cabled NIC, make sure the cable is properly connected on both ends. If the cable seems connected correctly, make sure others connected to the hub can properly connect to the Internet or whatever Network resource that you cannot reach. If others have the same problem, check the hub or replace it. If others do not have the problem, try a different cable. If the connection is wireless, make sure other systems are connecting. If not, check the wireless hub and replace it if necessary. If others have no issues, check the hub to verify that your system has not been blocked by a filter list. The firewall can also be checked to see if your system has been blocked. STEP 5 The next step is to verify that you can send and receive packets to/from the Gateway on the LAN side as well as from the Internet side. NOTE: Some companies may not use a Gateway as a connection to the Internet, but use it for connecting to a Wide Area Network (WAN). The process explained here works the same. Gateways have an IP Address for the local connection to the LAN. The Gateway device also has another connection to the Internet or WAN. The other side also has an IP Address. Pinging both of them assures the system can reach the local side of the Gateway. By pinging the other side of the Gateway, you assure yourself that the Gateway is not blocking your access to the Internet or WAN. The address of the local side of the Gateway was found in Step 1. If the ping is successful, try to ping the other side of the Gateway. If the ping fails, the problem should be between the hub and the Gateway device itself. Make sure the Gateway device is turned on and connected to the network properly. The network administrator should be able to let you know the IP Address of the WAN side of the Gateway. Once you ping this address, you can determine if the Gateway allows your packets to pass through, or if they are being blocked. NOTE: It is not necessary to ping the outer side of the Gateway since you can test the ability in Step 6. STEP 6 By pinging an IP Address on the other side of the Gateway, one that is not on the LAN, you can tell if packets are going through the Gateway. You can ping an address that is not on your local network by pinging an Internet system if you have Internet access through the Gateway. NOTE: Do not ping by a Domain Name yet. Use an actual address. A small list of addresses to ping are as follows (these are DNS Servers): 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 If you can ping any of these addresses, then your TCP/IP and Network device is functioning, even though there can be other issues to cause problems. As I had mentioned before, the Gateway has two addresses. To find the outer IP Address with Windows or Linux, you need to visit http://whatismyipaddress.com/. If needed, perform this task at a system which works to get the outer Gateway address. If you can ping the outer Gateway address, the the Gateway is not blocking your system. If you cannot ping the outer address, contact a System Administrator who can remove your system from the blocked list. Most people may say to use Windows 'tracert' or the Linux 'traceroute' command, but these do not show the Gateway address. NOTE: If not installed, you will need to get 'traceroute' from your repository. Now, as you may have noticed, all pings have been using numeric IP Addresses. You should try to ping an address by name, such as: 'ping -c 5 google.com'. You should have an output similar to Figure 4. FIGURE 4 Here, you can see that the DNS Name 'google.com' has been resolved to the IP Address of 126.96.36.199. If the ping does not work, the try to ping the address directly by typing: 'ping -c 5 188.8.131.52'. If this works, but the name 'google.com' did not work, then you have a DNS problem. We now need to find the DNS servers that your TCP/IP is using to resolve names to addresses. The command is as follows: nm-tool You should get an output similar to Figure 5. Find the section for your NIC, mine is wlan0. At the bottom of the section is a list of your DNS servers. Make note of these and then ping them one at a time. If they fail, then you need a new DNS server. The listed one is unavailable for some reason. In the Terminal, log in as root and edit the file '/etc/resolv.conf'. Add two lines with the DNS Server address; an example follows: FIGURE 5 nameserver 184.108.40.206 nameserver 220.127.116.11 NOTE: You can use any of the IP Addresses in the list above. You may want to ping all of them to find two which have the quickest turnaround time. Once done, save the file and then try to ping a website or server by name again. It should work. If it does not work, there may be an issue with the DNS servers, so try others. If they respond to a ping, they should work fine. For more information on DNS, see http://www.linux.org/threads/tcp-ip-service-domain-name-system-dns.4849/.