TCP/IP for Linux

Table of Contents

1. Introduction
2. TCP/IP Basics
3. Subnet Addressing/CIDR
4. DNS
5. DHCP
6. Ports
7. Installing TCP/IP for Linux
8. Configuring TCP/IP for Linux
9. Troubleshooting Tools

Introduction

• TCIP/IP is probably the best supported network protocol in use today. It is the "official" protocol of the Internet. Windows, all Unix including Linux, apple, and novell all support TCP/IP.
• This seminar will take exclusively about IPv4 and not touch on IPv6. Due to time constraints, IPsec will also not be discussed.
• The purpose of this seminar is to give you a good introduction into TCP/IP. It won't make you an expert, and for the sake of time, I have to skip some things. However, it will try to teach you basic configuration and troubleshooting skills. Thrown in is a security "trick" that makes an excellent supplement to any firewall you might be running.

TCP/IP Basics

• Every computer (or device) directly connected to the Internet MUST have it's own IP address and that address must be unique.
• Every current IP address is composed of 32 bits, generally separated into groups of 8 to make it more human readable. Each group of 8 bits is called an octet.
• A bit is binary and is either a 0 or 1.
• The numbers for each set of 8 bits, when converted to decimal range from 0 to 255. The octets are separated by dots. For example, 192.168.4.1 is an IP address.
• Each IP address is composed of a network part and a host part, determined by the subnet mask.
• To really understand how the IP numbers work and are derived (especially for subnetting), you MUST learn binary to decimal conversions.
• TCP/IP is virtually a universal protocol. All major (and most minor) OS's support it.

Binary Overview

• Binary has only 0 and 1; no other digits.
• For example 12 is 1100 in binary.
• In writing IP addresses, if there aren't 8 binary digits in any octet, then 0's are added to bring the total up to 8. For example, if the 12 above was part of an IP address, it would be written as 00001100 in binary.
• Use the following table to convert between decimal and binary.:

Binary	1	1	1	1	1	1	1	1
Decimal	128	64	32	16	8	4	2	1

• To use the table, pick the largest decimal number in the table that is smaller than or equal to your number. This is the first 1 in binary. Take the difference of the two numbers and repeat until the difference is 0. All other bits are 0.
• Using the 12 example, the first digit that is smaller than 12 is 8. The difference between 12 and 8 is 4. Next we find a 4. We are done.

Binary	0	0	0	0	1	1	0	0	=>gives 00001100
Decimal	0	0	0	0	8	4	0	0	=>8 + 4 equals 12

Disguising the IP address

Some spammers try to disguise their IP address by using a nonstandard IP addressing scheme. For instance, a mythical spammer URL might read:

http://3232236545/getrippedoff.html

To decode the IP address, 3232236545, do the following:

1. Convert the number 3232236545 to binary. Using a program to do the conversion is easiest. The binary form of the number is 11000000101010000000010000000001
2. The number you got should be 32 digits long. If it isn't, add enough 0's at the beginning to make it 32 digits long. In our example, it is already 32 digits long.
3. Break the binary number up into 4 groups (or octets) of 8 digits each: 11000000.10101000.00000100.0000001
4. Now convert each octet into its decimal equivalent: 11000000 => 192; 10101000 => 168; 00000100 => 4; 00000001 => 1
5. The "mysterious" IP address is 192.168.4.1

IP address Rules

Not just any set of numbers can be a valid IP address; there are rules.

• No octet can be greater than 255.
• The first octet cannot be 127. This is reserved for the loopback network.
• A network ID of all 1's or 0's (in binary) is not valid. Neither is a host ID of all 1's or 0's (in binary). More on these later.
• The IP address within any set of interconnected networks must be unique.
• IP addresses with the first octet equal to or greater than 224 are reserved and should not be used.

Reserved IP addresses

The following IP addresses are reserved for private use, and should be used for internal networks:

• 10.0.0.0-10.255.255.255
• 172.16.0.0-172.31.255.255
• 192.168.0.0-192.168.255.255

The range 127.0.0.0-127.255.255.255 is also reserved for the loopback network and should not be used.

Despite the above addresses being reserved, this does not mean you will never see them on the Internet. IP addresses from crackers and script kiddies can be forged, and other instances are the result of misconfiguration. It is a good idea to block these addresses at your firewall or router if possible, both incoming and outgoing. Most ISP's don't filter these addresses very well, if at all.

Subnet Addressing/CIDR - Subnet Mask

• Every IP address consists of a network ID and a host ID.
• A host is some network device, usually a computer, but it could be another device, such as a printer.
• A network is a logical and sometimes physical collection of hosts. Networks are connected to each other by routers (and sometimes gateways).
• A subnet mask is used the computer to tell what part of the IP address is the network ID, and what part is the host ID.
• A subnet mask is not optional. If you have an IP address, you must have a subnet mask.
• A subnet mask in binary is a 32 digit string of 1's then 0's, in that order. No 1's may appear after the first 0.
• The bits in the IP address that match 1's in the subnet mask are the network ID, and the bits that match the 0's in the subnet mask are the host ID. The example that follows will help clear things up.
• Subnet masks can be written one of two ways. The older style looks very much like an IP address. For example 255.255.255.0 is a subnet mask. So is 255.255.255.240. The other, more modern way of writing a subnet mask is to just indicate how many 1's there are. For example, 255.255.255.0 written in the modern form would be 24, and 255.255.255.240 would be 28. Windows 98, 95, and NT use the old form. Some Linux apps use the old form too. Some Linux apps, such as IPCHAINS, can use either.

Subnet Addressing/CIDR - Example

A simple way to determine the network ID (or address) given a subnet mask is to convert both to binary, multiply digit wise, and the result is, in binary, the network address.

For example, given an IP address of 192.168.4.19/28 (or 192.168.4.19/255.255.255.240 in the old style) the result would be:

Notice that the IP address in this case, 192.168.4.16 would have a host ID of all 0's. This is why a host ID can't be all 0's. All 0's means this network.

Classes

The old style of assigning subnet masks was to use classes. Of course, subnetting, or supernetting would change the subnet mask. Still, it did, and still does, give you the best CHANCE of correctly guessing the subnet mask. The following table gives you the rundown:

Note that class D is for multicasting (not covered) and class E is reserved/experimental. Do not try to use these as an IP address for your system. In fact, any class E address you see on your Internet interface are likely forged packets (or the result of a misconfigured/messed up program). Also, 127.x.x.x is left out of the table because it is reserved for the loopback network.

Guessing the Subnet Mask Example

Guessing the subnet mask is rather risky. Given the address 192.168.18.18, what is the correct subnet mask? What network is it on? Answer: It's impossible to tell for sure. According to the class table, the subnet mask should be 255.255.255.0 and the network would be 192.168.18.0. However, it doesn't have to be. Here are a few of the possibilities:

Because the entire 192.168.x.x range of IP numbers is reserved for private (non-Internet) use, all the possibilities in the above table are perfectly valid and legitimate IP/subnet mask pairings.

Advantages of CIDR over IP classes

One reason classes aren't so great is that they lock you into a fixed size of your network. The only way to get any flexibility is to subnet. Take a look at the following table:

Suppose your company had a network with 500 hosts, and would never add any additional hosts. Under the class system, Class C would be too small, so your company would have to be assigned a Class B network address. However, this wastes a whole lot of usable IP addresses. Since there is a finite number, this is a problem. One, temporary, answer was to do away with the classes and go to CIDR. With CIDR, you can, in theory, get a network sized almost exactly to your needs. In this example, one solution is to assign 192.168.0.1/23 which allows for 510 hosts.

Another solution is to subnet. Some feel, including this author, that subnetting and CIDR are essentially the same thing.

What is subnetting and why would I want to do it?

Subnetting:

• is the act of take your original IP range and breaking it into a bunch of new, smaller, networks.
• permits physically remote local networks to be connected.
• allows a mix of network technologies to be connected, such as ethernet on one segment and token ring on another.
• reduces network congestion as broadcasts and local network traffic are limited to the local segment.

Each new network you create by subnetting requires its own, unique, network ID.

Subnet Sizing

The first thing you have to do to subnet is figure out what size you want the new segment(s) to be. To calculate the number of hosts and/or the number of networks on your new subnet, use the following formulas:

Note that i+j must equal the number of host bits in your original, assigned subnet mask.

How is this formula derived? The following refers to the binary numbers, not decimal. Remember that every time you add an additional bit, the number of possibilities doubles. For example:

This should, hopefully, explain where the 2^x part comes from.

The "- 2" for hosts comes into play because a host ID of all 0's means, in TCP/IP, this network. It is not a valid host ID. A host ID of all 1's means a broadcast to everyone on this network. It too is not a valid host ID. Hence, 2 must be subtracted from the number of hosts in the formula. Note that with every new (sub)network, you lose 2 possible hosts. Therefore, it becomes tricky to size properly. To many new networks, and you run out of IP's. To few, and you don't have enough networks.

Subnet Sizing continued

The formula for networks assumes you are subnetting (or perhaps supernetting), not looking at the whole 32 bit range (which isn't available anyway). FYI, for networks, a network ID of all 0's means a specific host on the local network. It is not a valid network, and is used for DHCP (in the form of 0.0.0.0/32, which is a broadcast source), but I have yet to encounter any other use. On the other end of the spectrum, a network of all 1's is a broadcast, meaning everybody. It is also not a valid network, except for DHCP where an address of 255.255.255.255/32 is a broadcast destination. If you aren't using DHCP, these addresses should be blocked at your firewall.

Given that you are subnetting, a certain number of bits are already mandated by whoever assigned you your network range. You can borrow additional bits from the host ID to make more networks. However, there are limits as to how many bits you can borrow. In some texts, the formula for networks 2ⁱ will instead be written as 2ⁱ -2 . This is because RFC 950 originally forbade the use of the subnetted network IDs where the bits being used for subnetting are set to all 0's (the all-zeros subnet) and all 1's (the all-ones subnet). The all-zeros subnet caused problems for early routing protocols and the all-ones subnet conflicts with a special broadcast address called the all-subnets directed broadcast address.

However, RFC 1812 did away with the limitation and allows the use of the all-zeros and all-ones subnets in a Classless Interdomain Routing (CIDR)-compliant environment. CIDR-compliant environments use modern routing protocols which do not have a problem with the all-zeros subnet and the use of the all-subnets directed broadcast has been deprecated. Before you use the all-zeros and all-ones subnets, verify that they are supported by your hosts and routers. Linux supports the use of the all-zeros and all-ones subnets.

An example of this would be the subnet mask 255.255.255.128 (original was 255.255.255.0) . Under the old system this isn't a valid subnet mask. The .128 part uses only 1 bit for the subnet ID. Since 1 bit can only be 0 or 1, it is an all 0's and all 1's subnet ID. Under CIDR, it is valid, and you don't waste as many numbers.

Another limitation of this formula is you have an upper limit as to how many host ID bits you can borrow for your subnet ID. You must leave at least 2 bits for the host ID.

Subnetting Example

1. Your boss sends you a memo. Starting with the network 192.168.4.0/24 (255.255.255.0 in the old form), break the old network into 7 new subnetworks with at least 35 hosts per network.
2. Being a very knowledgeable IT person, unlike your boss, you know that all your systems are RFC1812 compliant, so you can have all 0 and all 1 subnets.
3. Looking at the formulas above, the smallest number of bits you can borrow from the host ID to come up with at least 7 subnetworks is 3. (2² = 4, not big enough, 2³ = 8 big enough).
4. Since there are only 8 host bits in the original network, and you are using 3 for the new subnets, that leaves 5 bits for the new hosts. 2⁵ -2 = 32 -2 = 30. It is not possible to make this subnet.
5. You go back to your boss and tell him it's impossible. He calls you an idiot who can't understand that he said 3 networks, not 7. You show him his memo, to which he responds that his dumb secretary mistyped it. His "dumb" secretary overhears this, and books his next business flight with 15 layovers through airports with really bad security, to "save money".
6. With only 3 networks, you must borrow only 2 bits from the host ID. (This give 4 networks.) This leaves 6 bits for the host ID's. 2⁶ -2 = 64 -2 = 62, more than meets the requirements given to you. Therefore the new subnet mask will be /26 (or 255.255.255.192 in the old form).
7. The new networks are:

Subnet	IP Range (Not host!)
1	192.168.4.0 - 192.168.4.63
2	192.168.4.64 - 192.168.4.127
3	192.168.4.128 - 192.168.4.191
4	192.168.4.192 - 192.168.4.255

DNS - What is it?

DNS stands for Domain Name System. Computers don't think in words or letters; computers think in numbers only. A name like www.hlug.net means nothing to a computer. Humans on the other hand, like words. What does the site at 204.251.209.49 contain? In this case it is currently the site aka www.hlug.net . DNS is a way to convert names and numbers back and forth (among a few other things we won't get into).

Imagine for moment there was no DNS. Whenever you wanted to go somewhere on the web, you have to type in the IP address, rather than a name. Also, email address had to be followed by numbers, not names. For instance suppose instead of writing root@localhost, you had to write root@127.0.0.1 . That wouldn't be very convenient for you. It's not hard to imagine people would start compiling lists of IP address and what they are such as:

Well, DNS is just a very fancy form of that list. Before DNS when the Internet was far, far, smaller, people did in fact use a list. Using a list to find an IP address still exists today. In both Linux and Windows, the list is called hosts (Windows also has another list called lmhosts, but that is for a slightly different purpose). In Linux, hosts is generally found in the /etc directory.

Here is what my hosts file looks like:

127.0.0.1               localhost localhost.localdomain
192.168.4.179           newlinux

Your hosts file will probably have the first line, but may or may not have any other lines. The format of the file is pretty simple. First is the IP address, separated by some whitespace, then one or more host names, each separated by whitespace.

DNS - Why use it?

• While the hosts file will translate IP addresses and site names (called resolving), it suffers some serious drawbacks.
• Anytime an IP address changes, every hosts file in the world (or at least every file that has to know about the change) must be manually edited to reflect the new change. Considering the size of today's Internet, that's impossible.
• In general, try to avoid putting anything in the hosts file that will change.
• However, some people use a trick where they put in a fake IP address (usually 127.0.0.1) for certain sites they don't want to see, such as doubleclick.

Note that since DNS just returns an IP address (oversimplifying), you may use an IP address instead of a name. For example, typing in your web browser http://204.251.209.49 takes to the same place as typing in http://www.hlug.net . However, you should avoid using IP addresses when you can. An IP address can change without notice. DNS will note the change and give you the correct IP number.

The Birth of DNS

• DNS is like a giant hosts file, that is broken into many little pieces (called zone files).
• Each piece (or sometimes multiple pieces) is stored on a separate server.
• Each server has one or more people responsible for making sure their piece of the file is keep up to date.
• Whenever you need a hostname resolved, your computer contacts the computer that holds that piece (either directly or indirectly), called a nameserver or DNS server, and asks that computer to resolve that address.
• It doesn't matter whether your hosts file is up to date or not, just so long as the other computer's "hosts"/zone file is up to date.
• This breaking up the file makes it far more manageable.

Which Nameserver Holds the Correct Piece?

An example using www.hlug.net

• Each section of a hostname is read from right to left. net then hlug then www
• DNS is organized in a tree like structure, with the last part of the name being the top of that tree.
• In this example, the top of the tree is net.
• Each tree top is also known as a top level domain. There are currently many top level domains, and new ones can be added.
• Every DNS server [properly configured] has a list of servers that hold the piece of the zone file that represents the top level domains. This is "manually entered".
• Each top level domain server contains the nameserver that serves the next part of hostname and returns this information.
• Your DNS client then contacts the top level domain nameserver for the nameserver of second part of the name.
• The hlug.net domain nameservers are 204.251.209.8 or 204.251.209.9 (back up servers are common).
• Finally, the server at 204.251.209.8 (or .9) is asked for the IP address of www.hlug.net, which it returns (hopefully).
• Note that this example only had to ask 2 nameservers. In practice, it could take asking many more before your computer gets the IP address.

Configuring DNS

• In DNS there are two pieces of software involved (oversimplifying). There is client software and server software.
• The most common DNS server software used on Linux is BIND (aka named). Unless you want the ability to answer other computer's requests for information, you don't need to (and for security reasons, probably shouldn't) enable BIND.
• If you still want to set up BIND, see the DNS-HowTo.
• To ask DNS servers to resolve your hostname requests, you MUST be given the IP numbers of some DNS servers you can contact.
• If the DNS server IP address(es) are given by DHCP, you don't have to do anything (other than make sure you DHCP client is working properly). Many dial-up users get their DNS numbers this way.
• If you must enter the numbers by hand, the file to edit is called /etc/resolv.conf . Here is a sample /etc/resolv.conf:

        domain fake.my.domain.cxm
         search fake.my.domain.cxm my.domain.cxm
         nameserver 192.168.10.1
         nameserver 192.168.12.1

The format of resolv.conf is as follows:

1. domain followed by the local domain name. Multiple entries are not allowed. Optional
2. search followed by a list of alternate domain names to search for a hostname. Optional
3. nameserver followed an IP address of a domain name server to query when resolving names. Multiple nameserver lines (up to 3) are allowed, but each line can have only one IP address. Technically optional, but really, really, recommended.

Using the above resolv.conf example, if you asked your computer to resolve a host named robert, it would when using DNS, in order:

1. Contact the first nameserver listed, in this case 192.168.10.1 .
2. Ask that nameserver to resolve robert.fake.my.domain.cxm
3. If that nameserver did not answer, ask the next nameserver to do the resolving (192.168.12.1)
4. If the nameserver (whichever one) could not resolve robert.fake.my.domain.cxm, then your computer would try to resolve robert.my.domain.cxm .
5. If robert.my.domain.cxm could not be resolved, then your computer would try to resolve robert .
6. If robert did not resolve, you would get an error message.

Hosts and DNS

• Another file that is important for DNS is /etc/hosts.conf .
• hosts.conf controls whether the hosts file or DNS is used first, or even whether one is not used at all.
• Here is a sample /etc/hosts.conf that will work for you 99+% of the time:

        order hosts,bind                                          
        multi on  

• The

  multi on

  means to return all the valid IP addresses found, rather than just the first.
• This hosts.conf tells your computer to consult the hosts file first, then use DNS.

Ports

• Ports are a means of identifying and separating network based services. Your computer could in theory be taking to thousands of other different computers at the same time. Each conversation has an IP address and port number on both ends of the conversation (client and server). This is called a socket. So long as at least one number (IP address or port number) in the set is different, it is a different conversation. The port numbers are how the conversations keep from getting mixed up.
• Each TCP/IP address has 65536 different ports, ranging from 0 - 65535. This has security implications, which will be discussed later. Note that 2¹⁶ is 65536.
• Port numbers 0 - 1023 are called privileged ports, and for Linux, require root privileges to open. Note that this is different than connecting to the port! This is why any server listening on these ports must have root access at some point. Your /etc/services file lists the names associated with each port.
• Ports 1024 - 65535 are generally used for client side of the connection and do not require root privleges to open. They are also therefore, known as unprivleged ports. It is possible, however, to run servers on these ports. If a web server is running on ports other than port 80 (the default for http), common ones are port 8000 or port 8080.
• Your /etc/services files maps names to port numbers. In most configuration files, you can either use the name of the port as defined in /etc/services, or the port number.

Suppose you (at 192.168.1.1) want to visit a web site at 192.168.1.2. The setting up the a connection might go something like this.

• Your computer randomly picks a free port from the range 1024 - 65535. Any open port in this range will do. Say it picks 4567.
• Your computer contacts the web site at 192.168.1.2:80 (by default).
• Your conversation with the web server is defined by the socket 192.168.1.1:4567 and 192.168.1.2:80.
• This may not be, and probably is not an exclusive connection to port 80. Someone else could be talking to the same web server using another grouping, such as the socket 192.168.1.3:4567 and 192.168.1.2:80. This is a totally different conversation than yours, even though most of the numbers are the same.

Installing TCP/IP for Linux

All distributions I know of come with tcp/ip already installed. You don't need to do anything to install it!

Configuring the interface

There are number of good tools for this: linuxconf, netconf, netcfg, etc. However, for those that wish to do this by hand (and there is one good reason why)...The network interface configuration are stored in text files. In RedHat and Mandrake based systems, the files are in /etc/sysconfig/network-scripts. The files are ifcfg-. Examples include ifcfg-lo, ifcfg-eth0. All configuration directives take the form

Directive="somevalue"

The configuration directives are:

• DEVICE - the device name. Usually something like eth0, eth1, lo, etc. Examples:

  DEVICE="eth0"
  DEVICE="eth1"

• BOOTPROTO - How the ip address and some other things are assigned. Examples:

  BOOTPROTO="DHCP"
  BOOTPROTO="none"

  The last example is a statically assigned ip address indicator.
• IPADDR - The IP address assigned to this interface. Do not include the subnet mask, just put in the IP address. Examples:

  IPADDR="127.0.0.1"
  IPADDR="192.168.1.1"
  IPADDR=""

  The last example is a DHCP example.
• NETMASK - The netmask associated with the above IP address. See IPADDR
• ONBOOT - Do you want this interface brought up when rebooting your linux box. The choices are "yes" and "no".
• BROADCAST - The broadcast address for the network this interface is on. For DHCP, leave this value blank. Don't put "". Examples:

  BROADCAST="192.168.1.255"
  BROADCAST=

• NETWORK - The network address for the network this interface is on. The format is the same as for BROADCAST.
• USERCTL - Can ordinary users bring this interface up and down? This line is optional, and if you leave it out, the default is only root (or suid's!) can bring the interface up and down. This directive does not use ""'s. Example:

  USERCTL=yes

  Most configuration programs do not set this, including linuxconf, so if you want to enable this, you must do so by hand.
• There are also a number of configuration lines that can be added here for IPX, but that is beyond the scope of this lecture.

Troubleshooting tools

• ping
• netstat
• traceroute
• nslookup

ping

Background info

• Stands for Packet InterNet Gopher
• Uses ICMP packets. Type ("Port") 8 [echo request] as the source with no "port" in the destination, and returns type 0 [echo response] as the source "port" with no "port in the destination" (example below).
• Used primarily to determine if a host is "alive". It also gives some info on how good the connection to that host is.
• Is also commonly used to see if there is a good connection between two hosts. If ping fails, the "network" is the problem, not the application.
• Can take either an IP address or a host name. If given a host name, it try to resolve it first. This can be used as a primative nslookup substitute, especially on systems that don't have nslookup (or dig), such as Windoze.
• Linux version may be set such that only root can use ping. Also, the Linux version of ping will, unless given a switch, continue to send packets until the program (ping) is killed.
• Because ping can be used as a childish denial of service attack, many sites on the internet do not respond to pings. Many firewalls do not respond to pings either as doing so indicates an active computer at that IP address, and may invite further probing. This really cuts down on ping's usefulness. Yahoo does still respond to pings. Once everything is working correctly, you should also try pinging your nameservers. If sucessful, you have another host you can test against later if you have trouble.

Using Ping

• The most basic use is to give ping an ip address:

  ping 127.0.0.1

• A host name can be substituted instead of an ip address:

  ping localhost

• The -c switch will limit the number of packets sent. For example, to ping only 4 times (which is what the Windoze version does by default):

  ping -c 4 localhost

• The -R option will give the route the packets took. This makes it a simple form of traceroute. However, many systems ignore or discard the -R info, making it of limited use. In addition, the header is only large enough to store 9 routes, and the return path counts towards this total. Thus, if the target is more than 4 hops away, you won't get all the information (use traceroute instead). An example would be:

  ping -R localhost

• The man page lists many more options, but, IMHO, none of them particularly useful in day-to-day work.

Decoding the output

Here is a sample ping output with leading line numbers added:

1  [robert@newlinux ~] $ ping -R -c 4 keng     
2  PING keng.mydomain.cxm (192.168.4.13) from 192.168.4.179 : 56 data bytes
3  64 bytes from 192.168.4.13: icmp_seq=0 ttl=128 time=0.4 ms
4  NOP
5  RR:     newlinux.mydomain.cxm (192.168.4.179)
6          Keng.mydomain.cxm (192.168.4.13)
7          newlinux.domain.cxm (192.168.4.179)

8  64 bytes from 192.168.4.13: icmp_seq=1 ttl=128 time=0.3 ms NOP (same route)
9  64 bytes from 192.168.4.13: icmp_seq=2 ttl=128 time=0.3 ms NOP (same route)
10 64 bytes from 192.168.4.13: icmp_seq=3 ttl=128 time=0.3 ms NOP (same route)

11 --- keng.mydomain.cxm ping statistics ---
12 4 packets transmitted, 4 packets received, 0% packet loss
13 round-trip min/avg/max = 0.3/0.3/0.4 ms

Here's the line by line explaination:

1. [robert@newlinux ~] $ ping -R -c 4 keng

   The command that started the pinging. Here I want the path "-R", tell ping to only send 4 packets "-c 4" and give a hostname to pring "keng". Note that the hostname is not case sensitive.

2. PING keng.mydomain.cxm (192.168.4.13) from 192.168.4.179 : 56 data bytes

   This is the first output line from ping. Ping resolved the host name to "(192.168.4.13)". It also gives me the FQDN for the host keng as "keng.mydomain.cxm". Next, ping tells me which IP address it is sending the ping packets from "192.168.4.179". This is more useful when you have multiple interfaces on your machine, but gives you some information about how your routing table is setup. Finally, ping tells me how many bytes of data it is sending in each packet "56 data bytes". Note that there are 8 bytes of ICMP header data for a total packet size of 64 bytes. The number of data bytes can be changed.

3. 64 bytes from 192.168.4.13: icmp_seq=0 ttl=128 time=0.4 ms

   This is the first packet that came back. "64 bytes" came back, which is the same number sent out. This is normal. If the number differs, it means there is a problem somewhere between your computer and the other computer, possibly including the other computer. Next, ping tells you the IP address of the packet that just came back "192.168.4.13". This matches the address you sent the packet too. If it doesn't match, that means either someone is playing games on the other computer, or someone on the network is running a pretty lousy sniffer. The "icmp_seq=0" tells you that this is the first packet you sent (numbering starts at 0). All the sequence numbers should be sequental. If not it means there is a problem, probably on the line, but possibly to the other computer. Next up is "ttl=128" which is the time to live. It doesn't provide much useful information. Finally is "time=0.3ms" which tells you how long the packet took to get back to you. This is useful for gauging the speed of the connection. It is normal for this number to vary. A time of 0.3 ms means this is most likely on a low traffic local network.

4. NOP

   I have no idea what this stands for.

5. RR:     newlinux.mydomain.cxm (192.168.4.179)

   This is the start of the routing information. The source of the packet was my machine (as would be expected).

6. Keng.mydomain.cxm (192.168.4.13)

   More routing information. This says the next machine the packet visited was 192.168.4.13 . In this case, it happens to be the destination machine too.

7. newlinux.domain.cxm (192.168.4.179)

   This is the final destination of the packet.

8. 64 bytes from 192.168.4.13: icmp_seq=1 ttl=128 time=0.3 ms NOP (same route)

   This gives the same info as line 3, except the packet number is one higher (which it should be).
9. Same as line 3, except for the packet number.
10. Same as line 3, except for the packet number.

11. --- keng.mydomain.cxm ping statistics ---

    Formatting line for some summary statistics.

12. 4 packets transmitted, 4 packets received, 0% packet loss

    Shows how many packets were lost. 0% is the best (and usual) case.

13. round-trip min/avg/max = 0.3/0.3/0.4 ms

    Gives some round trip time info.

Using ping to troubleshoot

Note that you should always use IP numbers when troubleshooting unless you are 100% certain DNS is working ok.

1. ping 127.0.0.1 . If you can't ping this, this means either your firewall is misconfigured, or your TCP/IP protocol isn't starting up. The problem lies with your computer, otherwise, proceed to step 2.
2. Ping your interface by ip number. In the example above, it would be ping 192.168.4.179 . If you can't ping this, it means your interface is not working properly. It could just need to be started. If this works, proceed to step 3.
3. Ping your default gateway by ip number. Since it is possible, but not likely, your default gateway doesn't respond to pings, you should do this step when everything seems to be working ok. If your default gateway doesn't respond, the problem lies there (at least). If this works, or the gateway doesn't respond to pings, proceed to step 4.
4. Ping the remote system. It is possible, and if it is on the internet, likely that it doesn't respond to pings anyway. This should be determined ahead of time. You might need to try something else here, such as traceroute, or just seeing if they have a web page.
5. Finally, try pinging something by host name. If this fails, but the other tests suceed, that means something is wrong with DNS (or your hosts file).

netstat

Background info

• Displays network connections, routing tables, interface statistics, masquerade connections, netlink messages, and multicast memberships. We aren't going to cover all of these.
• Can be used to check for open ports, an important security issue! See below.
• Can also be used to check for Unix sockets (which are used for interprocess communication on the same computer), which have very little to do with IP and won't be discussed here.
• Can be used as a substitute for the route command.
• Can be used to display the packet information the same as ifconfig.

Using Netstat

• Just typing netstat with no options on the command line gives you IP sockets (called inet) and unix sockets. It is best to pipe the output to more or less, as it tends to scroll off the screen.
• The -A (case sensitive!) with either unix or inet will display only the unix sockets or inet (aka TCP/IP) sockets respectively. Note that this switch by itself does not list listening ports, only active . Also, a synonym for -A inet is --inet (and -A unix is --unix). By itself, this is not a very useful switch. See below.
• The -a (case sensitive!) lists all sockets, IP and unix, regardless of their state. Without the -a option, only sockets with "active" connections are listed. Th -a switch isn't documented very well in the man page or info page!
• The -n switch displays hostnames and port identifiers in numeric format rather than symbolic names. For example, www.hlug.net is a symbolic name, and 204.251.209.49 is a numeric format. If DNS isn't working, this avoids the long timeout period (which may still occur if some DNS servers don't have PTR records). Note that 0.0.0.0 and * both mean any. Use of -n is the user's choice. The port symbolic names come from /etc/services.
• The -p switch lists the name (and PID) of the program listening or using the socket. You must be logged on as root to use the -p option.
• It is very useful for security audits to combine the -p, -a, and --inet switches. An example is below.
• The -er switch will give you the exact same listing as route. It can be combined with the -n switch, just as route can.
• The -ei switch will give you the packet information for each interface. ifconfig will also give you the same information.
• The man page lists many more options, but, IMHO, none of them particularly useful in day-to-day work.

Decoding the output

Here is a sample (faked) netstat output with leading line numbers added:

1 [root@newlinux ~] # netstat -a --inet -p -n

2 Active Internet connections (servers and established)

Here's the line by line explaination:

1. This is the line that launched netstat. Here, I want all active inet sockets, by IP number only, with the program name. Note that is is run as root.
2. First line of output from netstat. Not much of importance here.
3. This is the header line.
   • Proto is which TCP/IP protocol the services is using, TCP or UDP (and in few case RAW)
   • Recv-Q is the number of bytes received from the remote host but not yet delivered to the local program. Beware if this is not 0 for a LISTEN state!
   • Send-Q is the flipside of Recv-Q. It is the number of bytes sent from the local program but haven't been acknowledged by the remote host.
   • Local Address is the local (your!) IP address and port number.
   • Remote Address is the other computer's (not yours!) IP address and port number.
   • State is the local address' connection state for TCP (UDP and RAW don't have connection states). The two important statuses are ESTABLISHED which is an active on-going connection, and LISTEN which means your computer is listening for a connection request. There are other intermediate states seen when a connection is being established or torn down. The man page describes these.
   • PID/Program Name is the process ID number and program name that owns the local address.
4. This line shows an active telnet session. Telnet is a tcp protocol, the session has been established. The local address is 192.168.1.1:23, and the other end of the connection is at 192.168.1.2:4567. The program that owns this socket is in.telnetd. This is the telnet server program, and server port 23 is the telnet port. Telnet is a very dangerous program to use.
5. This line is an email program (specifically sendmail) waiting for someone to connect to it. The local address is 0.0.0.0:25 which means sendmail is listening on port 25 (the SMTP port) on every interface. Unless you are operating a public mail server, this is very bad form. The every interface means your internet connection can be connected to. A better way to do this is to limit which interfaces your mail server listens on. In fact, you should try very hard to elminate any and all local addresses that start with 0.0.0.0 unless you want to offer that to the world. See 6 and 7.
6. This is a web server (probably Apache) listening for web requests only on the 192.168.1.1 interface (port 80). This means anyone trying to connect to the internet interface on port 80 looking for an Apache exploit is SOL. No one is listening, but you still have a web server for the intranet. To exploit this web server, someone would have to break in some other way and then come back through the 192.168.1.1 interface. This just raised the difficulty level tremedously, independent of having a firewall. (Having a firewall is still HIGHLY recommended.)
7. This is the same as line 6, except here the web server is listening on the loopback interface (127.0.0.1) rather than some other interface. If you are limiting interfaces that servers listen on, it's usually a good idea, and pretty safe, to add the loopback interface. Note that the same service (PID and program name) has more than one line in netstat. This is normal.
8. This line, and the next 2 lines are inetd listening for various connections on any interface. This demonstrates that a single service can listen on several different ports at the same time. In this case, ident is listening for auth requests.
9. See also line 8. In this case, inetd is listening for telnet connections on all interfaces. This is very risky from a security stand-point.
10. See also line 8. This line shows inetd listening for FTP requests on all interfaces.
11. This line is Samba listening for netbios name service UDP packets on the 192.168.1.1 interface. Note that since UDP is a stateless protocol, there is no state. The netbios name service is a form of DNS for microsoft networks.
12. This line is Samba listening for netbios datagram service UDP packets. See line 11 for more info.
13. This is almost the same as line 11, except this is Samba listening for netbios broadcasts. Samba will not respond (directly) to anything on this interface. This line will almost always be here if you are running Samba, even if you tell it to only work on select interfaces.
14. See line 13.

Traceroute

Background info

• Prints the route packets take to get to a particular network host.
• Traceroute uses a time-to-live trick to get each host/router along the way to "announce" itself.
• It sends out packets with increasing TTLs until it reaches the host, or a 30 hop limit.
• Uses UDP packets by default. There is a patch that allows GRE packets to be sent instead.
• By default, the source port starts at 33434 and increments by one with each new packet.
• It can be used to determine the path to a particular host, and the speed of each point on the way.
• Not all hosts and routers respond to traceroute.

Using Traceroute

• The most basic use is to give traceroute an ip address:

  traceroute 127.0.0.1

• A host name can be substituted instead of an ip address:

  ping localhost

  Note that DNS (or hosts) must be working first.
• The -n switch prints host names as ip numbers rather than names. This saves DNS lookups. Of course, some hosts don't have PTR records, so you won't get a name anyway.
• The -p switch allows you specify the starting port number. This is useful in getting a response from hosts that don't respond to the high, unprivleged port numbers traceroute uses by default. If anything is listening on the port you are using, you will not get a response though. Note the port number still increases by one with each hop. Some versions of traceroute have a switch to prevent this increase.
• The man page lists many more options, but, IMHO, none of them particularly useful in day-to-day work.

Decoding the output

Here is a sample traceroute output with leading line numbers added:

1    [robert@linux robert]$ /usr/sbin/traceroute www.hlug.net
2   traceroute to www.hlug.net (204.251.209.49), 30 hops max, 38 byte packets
3   1  adsl-208-191-175-254.dsl.hstntx.swbell.net (208.191.175.254)  23.491 ms  23.351 ms  28.194 ms
4   2  core2-vlan50.hstntx.swbell.net (151.164.11.126)  14.174 ms  15.819 ms  16.166 ms
5   3  bb1-g8-0.hstntx.swbell.net (151.164.11.246)  13.218 ms  15.009 ms  14.480 ms
6   4  sl-gw20-fw-6-3.sprintlink.net (144.232.194.73)  21.121 ms  20.283 ms  20.006 ms
7   5  sl-bb20-fw-5-0.sprintlink.net (144.232.11.125)  19.379 ms  20.658 ms  19.608 ms
8   6  sl-gw15-fw-0-0.sprintlink.net (144.232.0.137)  19.891 ms  20.663 ms  20.128 ms
9   7  sprintloopback.mylinuxisp.com (216.39.192.9)  28.781 ms  29.890 ms  29.462 ms
10 8  www.hlug.net (204.251.209.49)  29.969 ms  27.830 ms  32.932 ms

Here's the line by line explaination:

• 1 [robert@linux robert]$ /usr/sbin/traceroute www.hlug.net

  The command that started the traceroute. Here I used a host name rather than an ip address. Note that the hostname is not case sensitive.

• 2 traceroute to www.hlug.net (204.251.209.49), 30 hops max, 38 byte packets

  An informational line. The host name resolved to 204.251.209.49, the traceroute will only check the first 30 hops (there were only 10 in this case), and the udp packets are 38 bytes long.
• Lines 3 through 10 show the hops that the packets took to get to the host. In this case, we were lucky. All hosts returned an ICMP error message, and all host names have PTR records. Each host was tried 3 times, and the time it took the packets is given.
• The man page for traceroute has some other, more interesting examples with explainations.

nslookup

Background info

• Is a tool used to query DNS servers.
• Has two modes: interactive and noninteractive.
• The noninteractive mode is like ping, only it doesn't send any packets.
• Dig, not covered here, does almost the same thing, but the commands are different. There is some talk about nslookup being replaced by dig.

Using nslookup

• The most basic (noninteractivemode) use of nslookup is to give it a hostname to resolve:

  nslookup www.hlug.net

• This is one instance where you can't substitute an IP address for a hostname!
• To easiest way to enter interactive mode is just type nslookup with no arguments.

Types of DNS records (this is NOT an exhaustive list!)

• A - Gives the IP address associated with a hostname.
• NS - Tells what nameserver(s) are responsible for a particular domain(s) (and host).
• MX - Tells what mail server handles email for a particular domain(s) (and hosts).
• CNAME - An alias for a host name.
• PTR - Gives the hostname for a particular IP address.

nslookup interactive mode example

1. [robert@linux robert]$ nslookup

   The command that starts the interactive mode.

2. Default Server:  dns1-rcs.rcsntx.swbell.net

   Show which nameserver is the current default.

3. Address:  151.164.1.8

   Shows the address of the default nameserver

4. >

   Notice the prompt? nslookup is waiting for a command. After you enter a command (except for exit), nslookup returns another prompt. From here on, I will omit the next prompt.

5. > www.yahoo.com
   Server:  dns1-rcs.rcsntx.swbell.net
   Address:  151.164.1.8
   
   Non-authoritative answer:
   Name:    www.yahoo.akadns.net
   Addresses:  216.32.74.53, 64.58.76.176, 64.58.76.179, 216.32.74.55
   	  216.32.74.52, 64.58.76.177, 216.32.74.50, 64.58.76.178, 216.32.74.51
   Aliases:  www.yahoo.com

   This shows a lookup of www.yahoo.com. The DNS server that you asked (and returns the answer) is given as is it's address. It is a "non-authoritative answer", meaning it is a cached answer and could be wrong. Next is the DNS that is authoritative for www.yahoo.com. There are multiple addresses for www.yahoo.com, meaning there is a cluster of servers you connect to, not just one. This is done mostly to spread out the load. Aliases shows the various servers are known as www.yahoo.com, but that is not their real name.

6. > set q=ptr

   The "set q=" command tells nslookup what type of record I want returned. "A" records are the default. Now I want to know the hostname associated with a particular IP address.

7. > 216.32.74.53
   Server:  dns1-rcs.rcsntx.swbell.net
   Address:  151.164.1.8
   
   53.74.32.216.in-addr.arpa	name = www4.dcx.yahoo.com
   74.32.216.in-addr.arpa	nameserver = ns1.yahoo.com
   74.32.216.in-addr.arpa	nameserver = ns5.dcx.yahoo.com
   74.32.216.in-addr.arpa	nameserver = ns.exodus.net
   74.32.216.in-addr.arpa	nameserver = ns2.exodus.net
   ns1.yahoo.com	internet address = 204.71.200.33
   ns5.dcx.yahoo.com	internet address = 216.32.74.10

   This shows what is returned now that I am looking for a hostname from an ip address. This is known as a reverse lookup. The DNS server name and ip are given as before. Next is the line with the name returned, www4.dcx.yahoo.com. Notice that this is not www.yahoo.com. This is what the alias line above was referring to. Also listed are the name servers for that host. Notice also that the reverse lookup ip address is indeed reversed.





























---

---

Time-to-live

• Every packet sent out is given a "poison" that will eventually kill it. That poison is called the time-to-live or TTL.
• This is done so that packets that get caught in a large to endless loop will eventually die and not swamp the network.
• Every host that forwards the packet decreases the TTL by one.
• When a router (and not the final host) gets a packet with a TTL of zero, it supposed to return an error message (ICMP packet, type 3, aka destination unreachable) and the packet dies.
• Not all hosts do return an ICMP message, and some do so with a TTL value of whatever the packet had that caused the ICMP error message. Since in this case the packet had a TTL of zero, the error message will never reach you.