TCP handshake

The Transmission Control Protocol (TCP) level of the TCP/IP transport protocol is connection-oriented. That means that, before any data can be transmitted, a reliable communication channel must be created. To establish a connection, TCP uses a 3-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the  3-step handshake occurs (Explanation of the Three-Way Handshake via TCP-IP)

1. The active open is performed by sending a SYN packet to the server. In this packet  Synchronize sequence number flag set to 1. This make it the request to the server to synchronize the sequence numbers. It specifies its initial sequence number (ISN), which is incremented by 1, For example 8221821+1=8221822, and that is sent to the server.
2. In response, the server replies with a SYN-ACK packet in which both Acknowledgement field and Synchronize sequence number field set to 1. the server is acknowledging the request of the client for synchronization. At the same time, the server is also sending its request to the client for synchronization of its sequence numbers. There is one major difference in this segment. The server transmits an acknowledgement number (8221823) to the client. The acknowledgement is just proof to the client that the ACK is specific to the SYN the client initiated. The process of acknowledging the client's request allows the server to increment the client's sequence number by one and uses it as its acknowledgement number.
3. Finally the client sends a packet with ACK bit (Acknowledgement field) set back to the server. In this packet, the client is acknowledging the request from the server for synchronization. The client uses the same algorithm the server implemented in providing an acknowledgement number. The client's acknowledgment of the server's request for synchronization completes the process of establishing a reliable connection, thus the three-way handshake.

Please note that for each connection there is a send sequence number and a receive sequence number. The initial send sequence number (ISN or ISS) is chosen by the data sending TCP, and the initial receive sequence number (IRS) is learned during TCP handshake.

Example:

1. The initiating host (client) sends a synchronization (SYN flag set) packet to initiate a connection. Any SYN packet holds a Sequence Number. The Sequence Number is a 32-bit field TCP segment header. For example let the Sequence Number value for this session be x=8221821. Then 8221821+1=8221822 is sent to the server.
2. The other host receives the packet, records the  initial send sequence number (ISN or ISS) from the client, and replies with a packet with two control bits set: acknowledgment and synchronization (SYN-ACK). The Acknowledgment Number is a 32-bit field in TCP segment header. It contains the next sequence number that this host is expecting to receive (x + 1). The host also initiates a return session by generating its own initial Sequence Number called  the initial receive sequence number (IRS) with the value of  y.
3. The initiating host responds with a packet that contains the next Sequence Number (x+1) Acknowledgment bit set.  Also provided is the value of y + 1, which is the Sequence Number value of the other host (receive sequence number (IRS) )

Sequence Numbers

A fundamental notion in the design is that every packet of data sent over a TCP connection has a sequence number. Since every packet is sequenced, each of them can be acknowledged. The acknowledgment mechanism employed is cumulative so that an acknowledgment of sequence number X indicates that all octets up to but not including X have been received. This mechanism allows for straight-forward duplicate detection in the presence of retransmission. Numbering of octets within a segment is that the first data octet immediately following the header is the lowest numbered, and the following octets are numbered consecutively.

It is essential to remember that the actual sequence number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with sequence numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. The symbol "=<" means "less than or equal" (modulo 2**32).

The typical kinds of sequence number comparisons which the TCP must perform include:

• Determining that an acknowledgment refers to some sequence number sent but not yet acknowledged.
• Determining that all sequence numbers occupied by a segment have been acknowledged (e.g., to remove the segment from a retransmission queue).
• Determining that an incoming segment contains sequence numbers which are expected (i.e., that the segment "overlaps" the receive window).

In response to sending data the TCP will receive acknowledgments. The following comparisons are needed to process the acknowledgments.

• SND.UNA = oldest unacknowledged sequence number
• SND.NXT = next sequence number to be sent
• SEG.ACK = acknowledgment from the receiving TCP (next sequence number expected by the receiving TCP)
• SEG.SEQ = first sequence number of a segment
• SEG.LEN = the number of octets occupied by the data in the segment (counting SYN and FIN)
• SEG.SEQ+SEG.LEN-1 = last sequence number of a segment

A new acknowledgment (called an "acceptable ack"), is one for which the inequality below holds:

    SND.UNA < SEG.ACK =< SND.NXT

A segment on the retransmission queue is fully acknowledged if the sum of its sequence number and length is less or equal than the acknowledgment value in the incoming segment. When data is received the following comparisons are needed:

    RCV.NXT = next sequence number expected on an incoming segments, and
        is the left or lower edge of the receive window

    RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming
        segment, and is the right or upper edge of the receive window

    SEG.SEQ = first sequence number occupied by the incoming segment

    SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming
        segment

A segment is judged to occupy a portion of valid receive sequence space if

    RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

or

    RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

The first part of this test checks to see if the beginning of the segment falls in the window, the second part of the test checks to see if the end of the segment falls in the window; if the segment passes either part of the test it contains data in the window.

Actually, it is a little more complicated than this. Due to zero windows and zero length segments, we have four cases for the acceptability of an incoming segment:

    Segment Receive  Test
    Length  Window
    ------- -------  -------------------------------------------

       0       0     SEG.SEQ = RCV.NXT

       0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

      >0       0     not acceptable

      >0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
                  or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Note that when the receive window is zero no segments should be acceptable except ACK segments. Thus, it is be possible for a TCP to maintain a zero receive window while transmitting data and receiving ACKs. However, even when the receive window is zero, a TCP must process the RST and URG fields of all incoming segments.

We have taken advantage of the numbering scheme to protect certain control information as well. This is achieved by implicitly including some control flags in the sequence space so they can be retransmitted and acknowledged without confusion (i.e., one and only one copy of the control will be acted upon). Control information is not physically carried in the segment data space. Consequently, we must adopt rules for implicitly assigning sequence numbers to control. The SYN and FIN are the only controls requiring this protection, and these controls are used only at connection opening and closing. For sequence number purposes, the SYN is considered to occur before the first actual data octet of the segment in which it occurs, while the FIN is considered to occur after the last actual data octet in a segment in which it occurs. The segment length (SEG.LEN) includes both data and sequence space occupying controls. When a SYN is present then SEG.SEQ is the sequence number of the SYN.

Initial Sequence Number Selection

The protocol places no restriction on a particular connection being used over and over again. A connection is defined by a pair of sockets. New instances of a connection will be referred to as incarnations of the connection. The problem that arises from this is -- "how does the TCP identify duplicate segments from previous incarnations of the connection?" This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished.

To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. We want to assure this, even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique.

For each connection there is a send sequence number and a receive sequence number. The initial send sequence number (ISS) is chosen by the data sending TCP, and the initial receive sequence number (IRS) is learned during the connection establishing procedure.

For a connection to be established or initialized, the two TCPs must synchronize on each other's initial sequence numbers. This is done in an exchange of connection establishing segments carrying a control bit called "SYN" (for synchronize) and the initial sequence numbers. As a shorthand, segments carrying the SYN bit are also called "SYNs". Hence, the solution requires a suitable mechanism for picking an initial sequence number and a slightly involved handshake to exchange the ISN's.

The synchronization requires each side to send it's own initial sequence number and to receive a confirmation of it in acknowledgment from the other side. Each side must also receive the other side's initial sequence number and send a confirming acknowledgment.

    1) A --> B  SYN my sequence number is X
    2) A <-- B  ACK your sequence number is X
    3) A <-- B  SYN my sequence number is Y
    4) A --> B  ACK your sequence number is Y

Because steps 2 and 3 can be combined in a single message this is called the three way (or three message) handshake.

A three way handshake is necessary because sequence numbers are not tied to a global clock in the network, and TCPs may have different mechanisms for picking the ISN's. The receiver of the first SYN has no way of knowing whether the segment was an old delayed one or not, unless it remembers the last sequence number used on the connection (which is not always possible), and so it must ask the sender to verify this SYN. The three way handshake and the advantages of a clock-driven scheme are discussed in [3].

Knowing When to Keep Quiet

To be sure that a TCP does not create a segment that carries a sequence number which may be duplicated by an old segment remaining in the network, the TCP must keep quiet for a maximum segment lifetime (MSL) before assigning any sequence numbers upon starting up or recovering from a crash in which memory of sequence numbers in use was lost. For this specification the MSL is taken to be 2 minutes. This is an engineering choice, and may be changed if experience indicates it is desirable to do so. Note that if a TCP is reinitialized in some sense, yet retains its memory of sequence numbers in use, then it need not wait at all; it must only be sure to use sequence numbers larger than those recently used.

NEWS CONTENTS

• 200102 : Connection Maintenance ( )

Old News ;-)

Connection Maintenance

In order to maintain connection information, TCP initializes and maintains status information about each connection. The three main pieces of information that need to be maintained include the source and destination ports, the sequence numbers, and the window sizes.

Reliability

To ensure reliability, TCP is able to recover from data that is damaged, lost, duplicated, or delivered out of sequence. In order to do this, TCP assigns a sequence number to each byte transmitted. The receiving host's TCP must return an ACK for bytes received within a specified period. If this is not done, the data is retransmitted. Damaged data is handled by adding a checksum to each segment. If a segment is detected as damaged by the receiving host's TCP, it will discard the segment. The sender will resend the segment since the ACK was never sent.

Flow Control and Performance

To enforce flow control, there is a send and receive window. The receive window size is returned by each ACK. The sender uses this window size to determine how full the receive window is. This way, the sender can judge if it should throttle back the rate at which the segments are being sent.

The receive window size and the maximum TCP segment size are the two most important variables when optimizing for performance. TCP implements a sliding window. The objective of a sliding window protocol is to minimize the time the sender waits for acknowledgement for bytes received. This allows for maximizing throughput.

The sender sends the segment, and then has to wait until he receives an acknowledgement. Ideally, the sender would be allowed to continually pump out segments. The acknowledgements would be timed to exactly match depletion of the send window

Let's look at the implementation details on the send and receive sides to better understand these important concepts. On the send side, the stack builds the segment and sends it via an IP datagram. The maximum amount of bytes that can be sent in one segment is determined by the tcpsegmentsize parameter. Once the datagram is sent, the stack sets the retransmit timer. If there is no acknowledgment for the bytes sent within a predefined time, the segment is resent. The time between resending is based on an exponential backoff. If no acknowledgement is returned after 16 tries, the session is dropped.

The LM TCP/IP implements the Van Jacobson Slow Start algorithm to determine the initial retransmit timer value. As TCP segments are processed, the time between sending a segment to receiving an acknowledgement for the segment sent is recorded. The time it takes to send a segment and receive an acknowledgement is referred to as the Smooth Round Trip Time (SRTT). This value is calculated for each frame sent. If an acknowledgement is not received by the SRTT, the sender will resubmit and set the retransmition timer to 2*<initial SRTT>. If the sender still does not get a response, he resends the bytes and sets the retransmission timer to 4*<initial SRTT>. This loop keeps going until 16 tries have been made. For those of you familiar with Microsoft's implementation of NetBEUI, the initial value for the retransmission timer has the same functionality as the value for T1 that is settable in PROTOCOL.INI. The beauty of the implementation in TCP/IP is that it takes care of the smell and the mess of determining the round trip time, no matter how many hops or slow links must be traversed.

On the receiving end, the segment comes in via IP. The CHECKSUM is computed and verified, and then the segment is thrown into a resequence queue. The bytes are sent to the application if there are enough in sequence. At this point the second important timer, the delayed ACK timer, is set to 1/4 second. The delayed ACK timer has the same functionality as the T2 timer has for NetBEUI. The objective to increasing throughput is to never allow for there to be enough of a pause in traffic so that the delayed ACK timer fires. If it does, it means that the sending station is waiting for a response. There is no settable parameter for changing the value for the delayed ACK timer.

There are two network traffic situations that will effect whether the delayed ACK timer fires. The ideal network traffic scenario has the sending and receiving stations participating in a conversation where both sides are sending relatively small data chunks back and forth. This allows the receiver to piggyback the ACK on data being sent back. An example where this would occur in LAN Manager networks is for SMB transactions that are not using raw SMB I/O, or applications such as email that send short messages back and forth.

Typically, LAN Manager traffic is maximized for large file transfer performance by using "raw SMB I/O". Raw SMB I/O (or raw I/O as you'll hear it commonly referred to) allows up to 64K of data to be sent out as a single chunk. Better throughput is obtained because the SMB header is only contained in the first frames. All subsequent frames need only contain data. In addition, received data does not have to rely on the negotiated buffer size. Data is immediately placed in the application's buffer space, thus saving an extra copy from the redirector's buffer to the application's.

For one way traffic such as raw I/O or FTP, the adjustment of tcpwindowsize becomes critical for performance. The amount of bytes that are sent and the size of the receive window will determine whether the delayed ACK timer will fire. Each TCP/IP implementation determines how empty the receive window is before it will send an ACK. LM TCP/IP will send an ACK when the receive window has received enough data to fill at least 50% of the window and processed enough of the data so that the window is now greater than 50% empty. For example, figure 20 illustrates a receive window when tcpwindowsize equals 4K.

The sender then sends 3K of data. The receiver processes this data and sends it up to the application. At this point, the window is greater than 50% empty, so an ACK is sent to the sender.

Contrast this to an extreme case where the sender sends 500 bytes to a receiver whose window is willing to accept 4K. Since the receiving window never gets over the 50% threshold, the receiver does not send an ACK. If the sender does not have any more data to send it must wait for the ACK sent when the delayed ACK timer fires.

3-Way Handshake

The host that wishes to initiate a conversation sends out a segment with the SYN bit on. The SYN bit is located in the flag section in the TCP header. It is requesting the recipient to start a conversation. The recipient should acknowledge all bytes starting at a randomly generated number which will be referred to as x. The recipient sends back a frame with the SYN bit on, a randomly generated sequence number to indicate the starting byte for segments it may send (y), and acknowledges that it expects to receive the next segment with the byte sequence number set at x+1. Finally, the requestor sends back a segment with the sequence number set to x+1, the acknowledgement number set at y+1.

- - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary
M 1 AT&T 81A7CA U-B 0F71B1 DLC Ethertype=0800, size=60 bytes
IP D=[11.1.1.70] S=[11.1.1.69] LEN=24 ID=35
TCP D=43 S=42530 SYN SEQ=48062 LEN=0 WIN=1450

DLC: DLC Header -
DLC:
DLC: Frame 1 arrived at18:56:57.9310; frame size is 60 (003C hex)bytes.
DLC: Destination = Station AT&T 81A7CA
DLC: Source = Station U-B 0F71B1
DLC: Ethertype = 0800 (IP)
DLC:
IP: IP Header -
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 44 bytes
IP: Identification = 35
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 30 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 841D (correct)
IP: Source address = [11.1.1.69]
IP: Destination address = [11.1.1.70]
IP: No options
IP:
TCP: TCP header -
TCP:
TCP: Source port = 42530
TCP: Destination port = 43 (Nicname)
TCP: Initial sequence number = 48062
TCP: Data offset = 24 bytes
TCP: Flags = 02
TCP: ..0. .... = (No urgent pointer)
TCP: ...0 .... = (No acknowledgment)
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..1. = SYN
TCP: .... ...0 = (No FIN)
TCP: Window = 1450
TCP: Checksum = 17EE (correct)
TCP:
TCP: Options follow
TCP: Maximum segment size = 1450
TCP:

ADDR HEX ASCII
0000 08 00 6A 81 A7 CA 00 DD 01 0F 71 B1 08 00 45 00 ..j.......q...E.
0010 00 2C 00 23 00 00 1E 06 84 1D 0B 01 01 45 0B 01 .,.#.........E..
0020 01 46 A6 22 00 2B 00 00 BB BE 00 00 00 00 60 02 .F.".+........`.
0030 05 AA 17 EE 00 00 02 04 05 AA FF 53 ...........S

- - - - - - - - - - - - - - - - Frame 2 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary
2 0.0494 U-B 0F71B1 AT&T 81A7CA DLC Ethertype=0800, size=60 bytes
IP D=[11.1.1.69] S=[11.1.1.70] LEN=24 ID=80
TCP D=42530 S=43SYNACK=48063SEQ=179072001LEN=0 WIN=8192
DLC: DLC Header -
DLC:
DLC: Frame 2 arrived at18:56:57.9804; frame size is 60 (003C hex)bytes.
DLC: Destination = Station U-B 0F71B1
DLC: Source = Station AT&T 81A7CA
DLC: Ethertype = 0800 (IP)
DLC:
IP: IP Header -
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 44 bytes
IP: Identification = 80
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 32 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 81F0 (correct)
IP: Source address = [11.1.1.70]
IP: Destination address = [11.1.1.69]
IP: No options
IP:
TCP: TCP header -
TCP:
TCP: Source port = 43 (Nicname)
TCP: Destination port = 42530
TCP: Initial sequence number = 179072001
TCP: Acknowledgment number = 48063
TCP: Data offset = 24 bytes
TCP: Flags = 12
TCP: ..0. .... = (No urgent pointer)
TCP: ...1 .... = Acknowledgment
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..1. = SYN
TCP: .... ...0 = (No FIN)
TCP: Window = 8192
TCP: Checksum = 86D9 (correct)
TCP:
TCP: Options follow
TCP: Maximum segment size = 1450
TCP:
ADDR HEX ASCII
0000 00 DD 01 0F 71 B1 08 00 6A 81 A7 CA 08 00 45 00 ....q...j.....E.
0010 00 2C 00 50 00 00 20 06 81 F0 0B 01 01 46 0B 01 .,.P.. ......F..
0020 01 45 00 2B A6 22 0A AC 6C 01 00 00 BB BF 60 12 .E.+."..l.....`.
0030 20 00 86 D9 00 00 02 04 05 AA 02 04 ...........


- - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary
3 0.0042 AT&T 81A7CA U-B 0F71B1 DLC Ethertype=0800, size=60 bytes
IP D=[11.1.1.70] S=[11.1.1.69] LEN=20 ID=36
TCP D=43 S=42530 ACK=179072002 WIN=1450

DLC: DLC Header -
DLC:
DLC: Frame 3 arrived at18:56:57.9847; frame size is 60 (003C hex)bytes.
DLC: Destination = Station AT&T 81A7CA
DLC: Source = Station U-B 0F71B1
DLC: Ethertype = 0800 (IP)
DLC:
IP: IP Header -
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 40 bytes
IP: Identification = 36
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 30 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 8420 (correct)
IP: Source address = [11.1.1.69]
IP: Destination address = [11.1.1.70]
IP: No options
IP:
TCP: TCP header -
TCP:
TCP: Source port = 42530
TCP: Destination port = 43 (Nicname)
TCP: Sequence number = 48063
TCP: Acknowledgment number = 179072002
TCP: Data offset = 20 bytes
TCP: Flags = 10
TCP: ..0. .... = (No urgent pointer)
TCP: ...1 .... = Acknowledgment
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..0. = (No SYN)
TCP: .... ...0 = (No FIN)
TCP: Window = 1450
TCP: Checksum = B8E2 (correct)
TCP: No TCP options
TCP:


ADDR HEX ASCII
0000 08 00 6A 81 A7 CA 00 DD 01 0F 71 B1 08 00 45 00 ..j.......q...E.
0010 00 28 00 24 00 00 1E 06 84 20 0B 01 01 45 0B 01 .(.$..... ...E..
0020 01 46 A6 22 00 2B 00 00 BB BF 0A AC 6C 02 50 10 .F.".+......l.P.
0030 05 AA B8 E2 00 00 00 00 00 00 00 00 ............

Sniffer Output of the 3-Way Handshake

The TCP segment being sent out in frame 1 is requesting to start a conversation with the service on the remote host listening on port 43. The SYN bit is set. The initial sequence number (x) is 48062. There are two other important pieces of information that gets set when the SYN bit is set. This is the setting of the maximum window size, and the maximum segment size. As discussed earlier, these two parameters have the greatest effect on performance. In this case, the initiator was a DOS client running LM TCP/IP. The maximum window size is set by the tcpwindowsize parameter.

Maintaining the TCP Session

Once the connection is made, data can be sent back and forth. If the connection is idle for a reasonably long enough time, there needs to be a way to determine if the idleness is due to a station being down, or inactivity. In NetBEUI, the timer that determined how long to wait before sending a SESSION_ALIVE frame is the Ti timer. Both NetBIOS sessions that ride on top of TCP and TCP sessions use the tcpkeepalive parameter to determine how long before the station that originated the conversation should check to see if the remote station is still up. The default value is 600 seconds. The maximum value for tcpkeepalive is 1800 seconds. Every time a segment is sent or received the, keep alive timer is set to tcpkeepalive. In order to determine the state of the session, the host that initiated the session sends out a segment containing one byte of data with the sequence number reduced by 1. This elicits an out-of-sequence response from the remote host. If after 8 keep alive segments there is still no response, the connection will be terminated.

The tcpkeepalive parameter is particularly important when you are being charged for packets sent out. This is more common in Europe than in the US due to the heavier usage of X.25. In this environment, you would want to make the tcpkeepalive parameter as large as possible.

- - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary
3 0.3976 AT&T 81A7CA U-B 0F71B1 DLC Ethertype=0800, size=60 bytes
IP D=[11.1.1.70] S=[11.1.1.69] LEN=20 ID=10
TCP D=139 S=43540 ACK=3150787423 WIN=2048

DLC: DLC Header -
DLC:
DLC: Frame 3 arrived at 18:12:15.3991; frame size is 60 (003C hex) bytes.
DLC: Destination = Station AT&T 81A7CA
DLC: Source = Station U-B 0F71B1
DLC: Ethertype = 0800 (IP)
DLC:
IP: IP Header -
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 40 bytes
IP: Identification = 10
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes
IP: Time to live = 30 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 843A (correct)
IP: Source address = [11.1.1.69]
IP: Destination address = [11.1.1.70]
IP: No options
IP:
TCP: TCP header -
TCP:
TCP: Source port = 43540
TCP: Destination port = 139
TCP: Sequence number = 17034
TCP: Acknowledgment number = 3150787423
TCP: Data offset = 20 bytes
TCP: Flags = 10
TCP: ..0. .... = (No urgent pointer)
TCP: ...1 .... = Acknowledgment
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..0. = (No SYN)
TCP: .... ...0 = (No FIN)
TCP: Window = 2048
TCP: Checksum = B2F1 (correct)
TCP: No TCP options
TCP:

- - - - - - - - - - - - - - - - Frame 8 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary
8 50.7487 AT&T 81A7CA U-B 0F71B1 DLC Ethertype=0800, size=60 bytes
IP D=[11.1.1.70] S=[11.1.1.69] LEN=20 ID=12
TCP D=139 S=43540 ACK=3150787423 WIN=2048

DLC: DLC Header -
DLC:
DLC: Frame 8 arrived at 18:14:43.8098; frame size is 60 (003C hex) bytes.
DLC: Destination = Station AT&T 81A7CA
DLC: Source = Station U-B 0F71B1
DLC: Ethertype = 0800 (IP)
DLC:
IP: IP Header -
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 40 bytes
IP: Identification = 12
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 30 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 8438 (correct)
IP: Source address = [11.1.1.69]
IP: Destination address = [11.1.1.70]
IP: No options
IP:
TCP: TCP header -
TCP:
TCP: Source port = 43540
TCP: Destination port = 139
TCP: Sequence number = 17033
TCP: Acknowledgment number = 3150787423
TCP: Data offset = 20 bytes
TCP: Flags = 10
TCP: ..0. .... = (No urgent pointer)
TCP: ...1 .... = Acknowledgment
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..0. = (No SYN)
TCP: .... ...0 = (No FIN)
TCP: Window = 2048
TCP: Checksum = B2F2 (correct)
TCP: No TCP options
TCP:

- - - - - - - - - - - - - - - - Frame 9 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary
9 0.0026 U-B 0F71B1 AT&T 81A7CA DLC Ethertype=0800, size=60 bytes
IP D=[11.1.1.69] S=[11.1.1.70] LEN=20 ID=4862
TCP D=43540 S=139 ACK=17034 WIN=8192

DLC: DLC Header -
DLC:
DLC: Frame 9 arrived at 18:14:43.8124; frame size is 60 (003C hex) bytes.
DLC: Destination = Station U-B 0F71B1
DLC: Source = Station AT&T 81A7CA
DLC: Ethertype = 0800 (IP)
DLC:
IP: IP Header -
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 40 bytes
IP: Identification = 4862
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 32 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 6F46 (correct)
IP: Source address = [11.1.1.70]
IP: Destination address = [11.1.1.69]
IP: No options
IP:
TCP: TCP header -
TCP:
TCP: Source port = 139
TCP: Destination port = 43540
TCP: Sequence number = 3150787423
TCP: Acknowledgment number = 17034
TCP: Data offset = 20 bytes
TCP: Flags = 10
TCP: ..0. .... = (No urgent pointer)
TCP: ...1 .... = Acknowledgment
TCP: .... 0... = (No push)
TCP: .... .0.. = (No reset)
TCP: .... ..0. = (No SYN)
TCP: .... ...0 = (No FIN)
TCP: Window = 8192
TCP: Checksum = 9AF1 (correct)
TCP: No TCP options
TCP:

Sniffer Output of Keep Alive Traffic

Frame 3 is the last segment that contained data sent by U-B 0F71B1. U-B 0F71B1 is the physical address of the host that originally initiated the session. The sequence number is 17034. Frame 8 is sent out by U-B 0F71B1 with the sequence number of 17033. This is one less than what it should be, so AT&T 81A7CA (the physical address of the host participating in the session) sends a frame back with the acknowledgement set to 17034, telling the sender of the bad sequence number.

Closing Down the TCP Session

There are two ways to disconnect a TCP session. One is through a graceful shutdown, the other is by issuing a reset. Closing down gracefully requires four segments to go back and forth.

When the sender has finished sending data, it closes down its half of the connection by sending a segment with the FIN bit set. The receiver immediately acknowledges this by sending back a segment with the ACK bit set. The receiver then tells the application of the request for shutdown. This causes the application on the receiving end to send a segment with the FIN bit set. The sender acknowledges this and the conversation is terminated.

Sniffer output of a graceful termination.

- - - - - - - - - - - - - - - - Frame 7 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary

7 0.0028 U-B 0F71B1 AT&T 81A7CA DLC Ethertype=0800, size=60 bytes

IP D=[11.1.1.69] S=[11.1.1.70] LEN=20 ID=82

TCP D=42530S=43 FIN ACK=48071 SEQ=179072029 LEN=0 WIN=0

DLC: DLC Header -

DLC:

DLC: Frame 7 arrived at18:56:58.4115; frame size is 60 (003C hex)bytes.

DLC: Destination = Station U-B 0F71B1

DLC: Source = Station AT&T 81A7CA

DLC: Ethertype = 0800 (IP)

DLC:

IP: IP Header -

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: Total length = 40 bytes

IP: Identification = 82

IP: Flags = 0X

IP: .0.. .... = may fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 32 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 81F2 (correct)

IP: Source address = [11.1.1.70]

IP: Destination address = [11.1.1.69]

IP: No options

IP:

TCP: TCP header -

TCP:

TCP: Source port = 43 (Nicname)

TCP: Destination port = 42530

TCP: Sequence number = 179072029

TCP: Acknowledgment number = 48071

TCP: Data offset = 20 bytes

TCP: Flags = 11

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 0... = (No push)

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...1 = FIN

TCP: Window = 0

TCP: Checksum = BE68 (correct)

TCP: No TCP options

TCP:

ADDR HEX ASCII

0000 00 DD 01 0F 71 B1 08 00 6A 81 A7 CA 08 00 45 00 ....q...j.....E.

0010 00 28 00 52 00 00 20 06 81 F2 0B 01 01 46 0B 01 .(.R.. ......F..

0020 01 45 00 2B A6 22 0A AC 6C 1D 00 00 BB C7 50 11 .E.+."..l.....P.

0030 00 00 BE 68 00 00 00 00 00 27 FF 53 ...h.....'.S

- - - - - - - - - - - - - - - - Frame 8 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary

8 0.0040 AT&T 81A7CA U-B 0F71B1 DLC Ethertype=0800, size=60 bytes

IP D=[11.1.1.70] S=[11.1.1.69] LEN=20 ID=39

TCP D=43 S=42530 ACK=179072030 WIN=1450

DLC: DLC Header -

DLC:

DLC: Frame 8 arrived at18:56:58.4155; frame size is 60 (003C hex)bytes.

DLC: Destination = Station AT&T 81A7CA

DLC: Source = Station U-B 0F71B1

DLC: Ethertype = 0800 (IP)

DLC:

IP: IP Header -

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: Total length = 40 bytes

IP: Identification = 39

IP: Flags = 0X

IP: .0.. .... = may fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 30 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 841D (correct)

IP: Source address = [11.1.1.69]

IP: Destination address = [11.1.1.70]

IP: No options

IP:

TCP: TCP header -

TCP:

TCP: Source port = 42530

TCP: Destination port = 43 (Nicname)

TCP: Sequence number = 48071

TCP: Acknowledgment number = 179072030

TCP: Data offset = 20 bytes

TCP: Flags = 10

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 0... = (No push)

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...0 = (No FIN)

TCP: Window = 1450

TCP: Checksum = B8BE (correct)

TCP: No TCP options

TCP:

ADDR HEX ASCII

0000 08 00 6A 81 A7 CA 00 DD 01 0F 71 B1 08 00 45 00 ..j.......q...E.

0010 00 28 00 27 00 00 1E 06 84 1D 0B 01 01 45 0B 01 .(.'.........E..

0020 01 46 A6 22 00 2B 00 00 BB C7 0A AC 6C 1E 50 10 .F.".+......l.P.

0030 05 AA B8 BE 00 00 20 46 48 45 4C 46 ...... FHELF

- - - - - - - - - - - - - - - - Frame 9 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary

9 0.0017 AT&T 81A7CA U-B 0F71B1 DLC Ethertype=0800, size=60 bytes

IP D=[11.1.1.70] S=[11.1.1.69] LEN=20 ID=40

TCP D=43 S=42530FINACK=179072030SEQ=48071LEN=0 WIN=1450

DLC: DLC Header -

DLC:

DLC: Frame 9 arrived at18:56:58.4173; frame size is 60 (003C hex)bytes.

DLC: Destination = Station AT&T 81A7CA

DLC: Source = Station U-B 0F71B1

DLC: Ethertype = 0800 (IP)

DLC:

IP: IP Header -

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: Total length = 40 bytes

IP: Identification = 40

IP: Flags = 0X

IP: .0.. .... = may fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 30 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 841C (correct)

IP: Source address = [11.1.1.69]

IP: Destination address = [11.1.1.70]

IP: No options

IP:

TCP: TCP header -

TCP:

TCP: Source port = 42530

TCP: Destination port = 43 (Nicname)

TCP: Sequence number = 48071

TCP: Acknowledgment number = 179072030

TCP: Data offset = 20 bytes

TCP: Flags = 11

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 0... = (No push)

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...1 = FIN

TCP: Window = 1450

TCP: Checksum = B8BD (correct)

TCP: No TCP options

TCP:

ADDR HEX ASCII

0000 08 00 6A 81 A7 CA 00 DD 01 0F 71 B1 08 00 45 00 ..j.......q...E.

0010 00 28 00 28 00 00 1E 06 84 1C 0B 01 01 45 0B 01 .(.(.........E..

0020 01 46 A6 22 00 2B 00 00 BB C7 0A AC 6C 1E 50 11 .F.".+......l.P.

0030 05 AA B8 BD 00 00 20 46 48 45 4C 46 ...... FHELF

- - - - - - - - - - - - - - - - Frame 10 - - - - - - - - - - - - - - - - -

SUMMARY Delta T Destination Source Summary

10 0.0099 U-B 0F71B1 AT&T 81A7CA DLC Ethertype=0800, size=60 bytes

IP D=[11.1.1.69] S=[11.1.1.70] LEN=20 ID=83

TCP D=42530 S=43 ACK=48072 WIN=0

DLC: DLC Header -

DLC:

DLC: Frame 10 arrived at18:56:58.4272; frame size is 60 (003Chex)bytes.

DLC: Destination = Station U-B 0F71B1

DLC: Source = Station AT&T 81A7CA

DLC: Ethertype = 0800 (IP)

DLC:

IP: IP Header -

IP:

IP: Version = 4, header length = 20 bytes

IP: Type of service = 00

IP: 000. .... = routine

IP: ...0 .... = normal delay

IP: .... 0... = normal throughput

IP: .... .0.. = normal reliability

IP: Total length = 40 bytes

IP: Identification = 83

IP: Flags = 0X

IP: .0.. .... = may fragment

IP: ..0. .... = last fragment

IP: Fragment offset = 0 bytes

IP: Time to live = 32 seconds/hops

IP: Protocol = 6 (TCP)

IP: Header checksum = 81F1 (correct)

IP: Source address = [11.1.1.70]

IP: Destination address = [11.1.1.69]

IP: No options

IP:

TCP: TCP header -

TCP:

TCP: Source port = 43 (Nicname)

TCP: Destination port = 42530

TCP: Sequence number = 179072030

TCP: Acknowledgment number = 48072

TCP: Data offset = 20 bytes

TCP: Flags = 10

TCP: ..0. .... = (No urgent pointer)

TCP: ...1 .... = Acknowledgment

TCP: .... 0... = (No push)

TCP: .... .0.. = (No reset)

TCP: .... ..0. = (No SYN)

TCP: .... ...0 = (No FIN)

TCP: Window = 0

TCP: Checksum = BE67 (correct)

TCP: No TCP options

TCP:

ADDR HEX ASCII

0000 00 DD 01 0F 71 B1 08 00 6A 81 A7 CA 08 00 45 00 ....q...j.....E.

0010 00 28 00 53 00 00 20 06 81 F1 0B 01 01 46 0B 01 .(.S.. ......F..

0020 01 45 00 2B A6 22 0A AC 6C 1E 00 00 BB C8 50 10 .E.+."..l.....P.

0030 00 00 BE 67 00 00 20 46 48 45 4C 46 ...g.. FHELF

Sniffer Output of a Graceful Shutdown

In frame 7, the host requesting the session be terminated has the physical address of AT&T 81A7CA. The FIN bit is set, the sequence number equals 179072029. U-B 0F71B1 is the physical address of the receiver. When it receives the segment with the FIN bit set, it immediately returns a segment with the ACK bit set, and the acknowledgment number equal to 179072030. Frame 10 is issued by U-B 0F71B1 directed to AT&T 81A7CA with the FIN bit set and the acknowledgment number equal to 179072030. Finally, as shown in frame 11, AT&T 81A7CA acknowledges that it received the frame with the FIN bit set and the connection is closed.

A host that wishes to abruptly terminate a session via a reset sends a TCP segment with the RST bit set.

Closing a connection with a reset typically occurs when the receiving side goes down during a session, for example when sending data. It will also occur when LAN Manager clients are talking to LAN Manager for UNIX servers via TCP/IP. LAN Manager for Unix servers allow for NetBIOS retargeting. Retargeting allows the LAN Manager for Unix server to tell the client that requests a conversation on a well known port to retarget the conversation. Retargeting requires one extra session to be included. Therefore, if you are talking to LAN Manager for Unix servers, make sure tcpconnections is set to one more than needed for normal session traffic.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Microsoft/Explanation of the Three-Way Handshake via TCP-IP
• TCP Three-way Handshake (video)
• Inside the TCP Handshake Laura Chappell 01 Mar 2000
• Winsock Programmer's FAQ Debugging TCP-IP
• Three Way Handshake
• Transfer Control Protocol, 3-way handshake, TCP sliding window

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last Modified: March 12, 2019