client.com.38060 > telnet.com.telnet: S 3774957990:3774957990(0) win 8760 <mss 1460> (DF)

telnet.com.telnet > client.com.38060: S 2009600000:2009600000(0) ack 3774957991 win 1024 <mss 1460>

client.com.38060 > telnet.com.telnet: .ack 1 win 8760 (DF) client.com.38060 > telnet.com.telnet: P 1:28(27) ack 1 win 8760 (DF)

The section, "Establishing a TCP Connection," discusses the actual theory of this output. For now, however, look at the numbers in bold. The first two numbers in the first two lines in bold represent the very large ISNs in absolute format that are exchanged from client.com and telnet.com, respectively. The third line has a number in bold that represents a relative sequence number—1. This means that client.com has acknowledged receiving the previous SYN by telnet.com with an ISN of 2009600000. The 1 as the acknowledgement value means that the next expected relative byte to be received by client.com is byte 1. That would have an absolute sequence number of 2009600001, if it were not displayed as a relative sequence number. If this seems confusing, the theory of acknowledgement numbers will be discussed in more detail in the upcoming section "Introduction to TCP."

The final line has the numbers 1 and 28 in bold to indicate that relative to the absolute sequence number of 3774957990, the 1st byte through (but not including) the 28th byte are sent from client.com to telnet.com. The final line also has ack 1.. This acknowledgement

number will not change until telnet.com sends more data.

If you ever need to leave the sequence numbers in their absolute form, the TCPdump –S option will alter the default behavior of expressing TCP sequence numbers in relative terms after the exchange of the ISNs.

Changing the TCPdump Collection Interface

You might find that you want to read TCPdump traffic from a different interface than the default one. The default interface is the lowest number active one, not including the loopback interface. For instance, if you were on a Linux box and had two NIC cards, one might be known as eth0 and the next eth1. To change the default interface, the –i option of TCPdump is used. The following command will select ppp0

as the listening interface: tcpdump –i ppp0

Dumping in Hexadecimal

TCPdump does not display all the fields of the captured data. For example, the IP header has a field that stores the length of the IP header. How do you display this field if it is not available from the standard TCPdump output? There is a TCPdump command-line option (–x) that dumps the entire datagram captured with the default snaplen in hexadecimal. Hexadecimal output is far more difficult to read and interpret, but it is necessary to display the entire captured datagram.

To interpret TPCdump hexadecimal output, you need some reference material that discusses the format of the IP datagram headers and describes what each of the fields represents. (One such reference title is TCP/IP Illustrated, Volume 1, by W. Richard Stevens.) You then must translate hexadecimal to decimal for numeric fields and numeric to ASCII for character fields. Ethereal is probably the best tool to use for translation of TCPdump records that are stored in binary form with the –w tcpdump command line option; it can read TCPdump binary data as input.

Introduction to TCP

TCP is a reliable connection-oriented protocol used with well-known applications such as telnet or smtp. An application such as telnet cannot tolerate the uncertainty of the Internet Protocol that can lose datagrams or deliver them in a different order from which they were sent. TCP is the protocol that orchestrates and ensures reliability. It does so using the following mechanisms:

●Exclusive TCP connection. When a TCP session is established, the connection is exclusive and unique between the two hosts. This kind of connection is called a unicast connection. The negotiation of the unique session allows both sides to track the traffic exchanged between the two hosts.

●TCP sequence numbers. These provide a sense of chronology to the TCP data sent and received. A telnet command or exchange might take several packets known as TCP segments to transmit all the data. Data is assigned a TCP sequence number to uniquely identify the data in each segment being sent. Because the data might arrive in a different order from which it was sent, TCP sequence numbers are also used to reassemble the data in the correct order.

●Acknowledgements. Acknowledgements are used to inform the sender that data has been received. Acknowledgements are made to sequence numbers to identify the exact data received. If the sender does not receive an acknowledgement for specific data in a given time, it assumes that the data has been lost. The sender will retransmit what it believes was lost.

Establishing a TCP Connection

Figure 2.2 shows establishing a TCP connection is almost ceremonial in nature, involving what is commonly known as the three-way handshake. This is normally completed before any data is passed between two hosts. What is depicted is the client or source host initiating a connection to the server or destination host. The term client is used to mean the host requesting some kind of service from another host. A server is a host that listens on a well-known port number for requests of a particular service. TCP requires a destination port or service to be specified. Examples of destination ports are 23 (telnet), 25 (smtp), or port 80 (also known as the HTTP or the web server port).

Figure 2.2. The three-way handshake.

The three-way handshake proceeds as follows:

1. The client sends a SYN (SYNC) to signal a request for a TCP connection to the server.

2. If the server is up and offers the desired service, and can accept the incoming connection, it sends a connection request of its own signaled by a new SYN (SYNS) to

the client and acknowledges the client's connection request with an ACK (ACKC). This

is all accomplished in a single packet.

3. Finally, if the client receives the server's SYN and ACK of the SYN that the client sent and still wants to continue the connection, it sends a final lone ACK (ACKS) to the

server. This acknowledges that the client received the server's request for a connection.

After the three-way handshake has been executed in this manner, the connection has been established. Data can now be exchanged between the two hosts. If you examine the three-way handshake with a little more scrutiny, you will discover that two connections have really been established. The first is between the client and server and the second between the server and the client. This is because TCP is full duplex, which means that data exchanges can travel in either direction independently.

The following example shows the three-way handshake, using TCPdump to display the

exchange:

tclient.net.39904 > telnet.com.23: S 733381829:733381829(0) win 8760 <mss 1460> (DF)

telnet.com.23 > tclient.net.39904: S 1192930639:1192930639(0) ack 733381830 win 1024 <mss 1460> (DF)

tclient.net.39904 > telnet.com.23: . ack 1 win 8760 (DF)

In the first record, you see the client, tclient.net, attempt a connection to the telnet server, port 23, of telnet.com. You see the SYN flag set followed by the ISN, 733381829, and the same ending sequence number, 0 payload bytes in the parentheses. After that, you see a window size of 8760 and a maximum segment size (mss) that it advertises to the server. The window size of 8760 says that the client has an 8760-byte buffer for aggregated incoming data to this connection. The mss informs the destination host that the physical network on which tclient.net resides should not receive more than 1460 bytes of TCP payload (20-byte IP header + 20-byte TCP header + 1460-byte payload = 1500 bytes, which is the maximum transmission unit, or MTU, for Ethernet) at a time. In this case, even though the client, (tclient.net) can accept 8760 bytes of data, the physical medium on which it resides, most likely Ethernet, cannot accept more than 1460 bytes for a TCP payload size.

In the second record, you see telnet.com send a SYN and an ACK to tclient.net informing it that it is an available and willing participant in this connection and is willing to establish one of its own as well. telnet.com informs tclient.net of its ISN, 1192930639. This is also the ending sequence number because no data is sent; this is normal for the SYN/ACK records. The number following the ACK is the acknowledgement number, in this case, 733381830. Note that this value is the ISN advertised by tclient.net in the first record 733381829 plus 1. telnet.com has just acknowledged that it expects absolute byte number 733381830 as the next sequence number from tclient.net. telnet.com advertises a window size of 1024 and a maximum segment size of 1460.

In the final line, tclient.net sends the final lone ACK to telnet.com and acknowledges receiving the SYN/ACK flags from telnet.com. The value of 1 as the relative acknowledgement number indicates that it next expects the first byte from telnet.com. Also, notice that the sequence numbers have changed from absolute to relative values beginning with this record. Right after the destination part, following the colon, you see a period. Remember this is the placeholder

value when none of the PUSH, RESET, SYN, or FIN bits is set.

Server and Client Ports

In the past, more so than today, well-known server ports generally fell in the range of 1–1023. Historically under UNIX, only processes running with root privilege could open a port below 1024. These ports should remain constant on the host for which they are offered. In other words, if you find telnet at port 23 on a particular host one day, you should find it there the

next day. You will find many of the older well-established services in this range of 1–1023 (such as telnet on port 23 and smtp on port 25). Today, some of the newer services, such as AOL Instant Messenger, usually associated with TCP port 5190, don't tend to conform to this original convention. This is partially because there are more services than numbers in this range today.

Client ports, often known as ephemeral ports, are selected only for a particular connection and are reused after the connection is freed. These are generally numbered greater than 1023. When a client initiates a connection to a server, an unused ephemeral port is selected. For most services, the client and server continue to exchange data on these two ports for the entirety of the session. This connection is known as a socket pair and it will be unique. There will be only one connection on the Internet that has this combination of source IP and source port connected to this destination IP and destination port.

Someone from the same source IP might even be connected to the same destination IP and port. This user will be given a different ephemeral port, however, thus distinguishing it from the other connection to the same server and destination port. Two users on the same host might connect to the same web server. Although this is the same source IP, destination IP, and port (80), the web server can maintain who gets what by the ephemeral source ports involved.

Examine the three-way handshake exchange again, but this time in the context of client and

server ports:

tclient.net.39904 > telnet.com.23: S 733381829:733381829(0) win 8760 <mss 1460> (DF)

telnet.com.23 > tclient.net.39904: S 1192930639:1192930639(0) ack 733381830 win 1024 <mss 1460> (DF)

tclient.net.39904 > telnet.com.23: . ack 1 win 8760 (DF)

You see that tclient.net has selected ephemeral port 39904 on which to communicate and to connect to well-known port 23 of telnet.com. Any further exchanges after the three-way handshake are done using these two negotiated ports. After the connection is closed and some time has passed, tclient.net releases port 39904 for use by another connection. Port 23 of

telnet.com remains bound to the telnet service for additional telnet requests.

Connection Termination

You can terminate a session in two ways: the graceful method or an abrupt method. The graceful method is the phone conversation equivalent of you saying, "Thanks, but we're not interested," and hanging up on the telemarketer. This informs the telemarketer that the conversation is over and that he should now hang up and place another intrusive dinnertime call to some other hapless victim. The abrupt equivalent of this is just hanging up after you determine someone isn't worth your valuable time.

The Graceful Method

When the graceful TCP session termination method is conducted, one of the hosts, either the client or server, signals with a FIN to the other that it wants to terminate the session. The receiving host signals back with an ACK (to acknowledge the request). This terminates only half the connection. Then, the other host must initiate a FIN as well, and the receiving host needs to acknowledge this. Both sides need to initiate a FIN and acknowledge the other's FIN because TCP is full duplex. Both the client and server send data in an asynchronous manner, so both sides of the connection have to be individually terminated. Look at the following two TCPdump exchanges:

1.Client initiates a close with a FIN, and server does an ACK, as follows:

2.tclient.net.39904 >telnet.com.23: F 14:14(0) ack 186 win 8760 (DF)

telnet.com.23 > tclient.net.39904: . ack 15 win 1024 (DF)

3.Server initiates close with a FIN, and client does an ACK, as follows:

4.telnet.com.23 > tclient.net.39904: F 186:186(0) ack 15 win 1024 (DF)

tclient.net.39904 > telnet.com.23: . ack 187 win 8760 (DF)