Making a Connection with tcpdump, Part II
Part I of this article discussed tcpdump, a command-line utility that sniffs network traffic. Now let's see what it can do.
Using tcpdump we can analyze the PDUs that establish and terminate a TCP/IP connection. TCP uses a special mechanism to open and close connections. The tcpdump output below display data from different connection scenarios between host 192.168.2.10 and 192.168.2.165. The following tcpdump command and options were used to generate output:
#tcpdump -nn host 192.168.2.165 and port 23
Before examining the output, let's take a detour and get a brief overview of TCP/IP connection management. This small detour will assist those individuals who are new to protocols. To guarantee a reliable connection (startup and shutdown), TCP uses a method in which three messages are exchanged. The process is called a three-way-handshake. To startup a connection:
The requesting Host sends a synchronization flag (SYN) in a TCP segment to create a connection.
The receiving Host 192.168.2.165 receives the SYN flag and returns an acknowledgment flag (ACK).
The requesting Host 192.168.2.10 receives the SYN flag and returns it's own ACK flag.
A similar handshake process is used to close a connection using a finish flag (FIN).
To establish a connection, the sending host creates a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number. Data is segmented before it is sent. The sequence numbers allow the segments to be assembled in the correct order.
20:06:32.845356 192.168.2.10.1249 > 192.168.2.165.23: S 3263977215:3263977215(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
The receiving hosts responds with its own SYN flag and its initial sequence number. This segment also contains an ACK flag to acknowledge the sending host's SYN (segment 3263977215 +1). This type of acknowledgment is called expectational acknowledgment, because the receiver acknowledges the sequence number of the next segment it expects to receive.
20:06:32.845725 192.168.2.165.23 > 192.168.2.10.1249: S 48495364:48495364(0) ack 3263977216 win 32120 <mss 1460,nop,nop,sackOK> (DF)
The sending host acknowledges the SYN flag from the receiving host by sending another segment containing the . and ACK flags.
20:06:32.845921 192.168.2.10.1249 > 192.168.2.165.23: . ack 1 win 17520 (DF)
So far two flags, S and ., have been seen. There are five in total.
S: SYN (Synchronize sequence numbers - Connection establishment)
F: FIN (Ending of sending by sender - Connection termination)
R: RST (Reset connection)
P: PSH (Push data)
.: (No flag is set)
To terminate a connection, a segment containing a FIN flag is sent from host 192.168.2.165 back to the host with the open session.
20:07:32.916410 192.168.2.165.23 > 192.168.2.10.1249: F 147:147(0) ack 56 win 32120 (DF)
This may appear backwards, but trust me, it's not. Think of where the session is open--this is the point that is asking to close the connection. Host 192.168.2.10 acknowledges the FIN segment.
20:07:32.916680 192.168.2.10.1249 > 192.168.2.165.23: . ack 148 win 17374 (DF)
Then host 192.168.2.10 terminates it connection by sending a segment containing a FIN flag.
20:07:32.928907 192.168.2.10.1249 > 192.168.2.165.23: F 56:56(0) ack 148 win 17374 (DF)
Host 192.168.2.165 acknowledges the segment.
20:07:32.929121 192.168.2.165.23 > 192.168.2.10.1249: . ack 57 win 32120 (DF)
To establish a connection, host 192.168.2.10 sends a segment containing the IP address and port number of the host it want to connect to. The segment contains a SYN flag and the sending hosts initial sequence number.
05:28:00.080798 192.168.2.10.1063 > 192.168.2.165.23: S 3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
Host 192.168.2.165 acknowledges the SYN from host 192.168.2.10 by sending another segment containing the R (connection reset) and ACK flags.
05:28:00.080979 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 3034008468 win 0
Host doesn't take no for answer and tries again.
05:28:00.579420 192.168.2.10.1063 > 192.168.2.165.23: S 3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
But it receives the same result from receiving host.
05:28:00.579524 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win 0
A final attempt is made to establish a connection.
05:28:01.080114 192.168.2.10.1063 &glt; 192.168.2.165.23: S 3034008467:3034008467(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
Only three strikes in this ball game. Sending host gives up.
05:28:01.080225 192.168.2.165.23 > 192.168.2.10.1063: R 0:0(0) ack 1 win 0
Compare the outputs from an Establish Telnet Connection scenario and Telnet Connection Refusal scenario. The outputs from the receiving host are different. For the Telnet Connection Refusal scenario, the Telnet service was turned off at the receiving host using the /etc/inetd.conf file. If the service is not available, no connection can be established. Note to self: simple security measures turn off services not being used.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- RSS Feeds
- Validate an E-Mail Address with PHP, the Right Way
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
18 min 18 sec ago
- Reply to comment | Linux Journal
50 min 40 sec ago
- All the articles you talked
3 hours 14 min ago
- All the articles you talked
3 hours 17 min ago
- All the articles you talked
3 hours 18 min ago
7 hours 43 min ago
- Keeping track of IP address
9 hours 34 min ago
- Roll your own dynamic dns
14 hours 47 min ago
- Please correct the URL for Salt Stack's web site
17 hours 59 min ago
- Android is Linux -- why no better inter-operation
20 hours 14 min ago