Explanation of the Three-Way Handshake via TCP/IP The Transmission Control Protocol (TCP) level of the TCP/IP transport

protocol is connectionoriented. Connection-oriented means that, before any data can be transmitted, a reliable connection must be obtained and acknowledged. TCP level data transmissions, connection establishment, and connection termination maintain specific control parameters that govern the entire process. The control bits are listed as follows: URG: Urgent Pointer field significant ACK: Acknowledgement field significant PSH: Push Function RST: Reset the connection SYN: Synchronize sequence numbers FIN: No more data from sender There are two scenarios where a three-way handshake will take place: Establishing a connection (an active open) Terminating a connection (an active close)

Establishing a Connection
The following sequence shows the process of a TCP connection being established:

Frame 1:

As you see in the first frame, the client, NTW3, sends a SYN segment (TCP ....S.). This is a request to the server to synchronize the sequence numbers. It specifies its initial sequence number (ISN), which is incremented by 1, 8221821+1=8221822, and that is sent to the server. To initialize a connection, the client and server must synchronize each other's sequence numbers. There is also an option for the Maximum Segment Size (MSS) to be set, which is defined by the length (len: 4). This option communicates the maximum segment size the sender wants to receive. The Acknowledgement field (ack: 0) is set to zero because this is the first part of the three-way handshake. 1 2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,

win: 8192, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037

dst: 139 (NBT Session)

TCP: Source Port = 0x040D TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 8221822 (0x7D747E) TCP: Acknowledgement Number = 0 (0x0) TCP: Data Offset = 24 (0x18) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x02 : ....S.

TCP: ..0..... = No urgent data TCP: ...0.... = Acknowledgement field not significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......1. = Synchronize sequence numbers TCP: .......0 = No Fin

TCP: Window = 8192 (0x2000) TCP: Checksum = 0xF213 TCP: Urgent Pointer = 0 (0x0) TCP: Options

TCP: Option Kind (Maximum Segment Size) = 2 (0x2) TCP: Option Length = 4 (0x4) TCP: Option Value = 1460 (0x5B4)

TCP: Frame Padding

00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E. 00010: 00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B .,..@....K.k...k 00020: 02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02 .......}t~....`. 00030: 20 00 F2 13 00 00 02 04 05 B4 20 20 .........

Frame 2:

In the second frame, the server, BDC3, sends an ACK and a SYN on this segment (TCP .A..S.). In this segment 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. 2 2.0786 BDC3 --> NTW3 TCP .A..S., len: 4, seq: 1109645-1109648, ack: 8221823, win: 8760, src: 139 (NBT Session) dst: 1037 BDC3 --> NTW3 IP

TCP: .A..S., len:

4, seq: 1109645-1109648, ack: 8221823, win: 8760,

src: 139 (NBT Session) dst: 1037

TCP: Source Port = NETBIOS Session Service TCP: Destination Port = 0x040D TCP: Sequence Number = 1109645 (0x10EE8D) TCP: Acknowledgement Number = 8221823 (0x7D747F) TCP: Data Offset = 24 (0x18) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x12 : .A..S.

TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......1. = Synchronize sequence numbers TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238) TCP: Checksum = 0x012D TCP: Urgent Pointer = 0 (0x0) TCP: Options

TCP: Option Kind (Maximum Segment Size) = 2 (0x2)

TCP: Option Length = 4 (0x4) TCP: Option Value = 1460 (0x5B4)

TCP: Frame Padding

00000: 02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00 .`.;...`......E. 00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .,[.@....L.k...k 00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ...........}t`. 00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8.-......

Frame 3:

In the third frame, the client sends an ACK on this segment (TCP .A....). In this segment, 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. 3 2.787 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...., len:

0, seq: 8221823-8221823, ack: 1109646, win: 8760,

src: 1037 dst: 139 (NBT Session)

TCP: Source Port = 0x040D

TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 8221823 (0x7D747F) TCP: Acknowledgement Number = 1109646 (0x10EE8E) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238) TCP: Checksum = 0x18EA TCP: Urgent Pointer = 0 (0x0) TCP: Frame Padding

00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E. 00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B .(..@....O.k...k 00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .......}t....P.

00030: 22 38 18 EA 00 00 20 20 20 20 20 20

"8....

Back to the top

Terminating a Connection
Although the three-way handshake only requires three packets to be transmitted over our networked media, the termination of this reliable connection will necessitate the transmission of four packets. Because a TCP connection is full duplex (that is, data can be flowing in each direction independent of the other), each direction must be terminated independently.

Frame 4:

In this session of frames, you see the client sending a FIN that is accompanied by an ACK (TCP .A...F). This segment has two basic functions. First, when the FIN parameter is set, it will inform the server that it has no more data to send. Second, the ACK is essential in identifying the specific connection they have established. 4 16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823, ack:3462835714 begin_of_the_skype_highlighting 3462835714 end_of_the_skype_highlighting, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...F, len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src: 1037 dst: 139 (NBT Session)

TCP: Source Port = 0x040D TCP: Destination Port = NETBIOS Session Service

TCP: Sequence Number = 8221823 (0x7D747F) TCP: Acknowledgement Number = 1109646 (0x10EE8E) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x11 : .A...F

TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......1 = No more data from sender

TCP: Window = 8760 (0x2238) TCP: Checksum = 0x236C TCP: Urgent Pointer = 0 (0x0)

00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E. 00010: 00 28 9B F5 40 00 80 06 21 begin_of_the_skype_highlighting end_of_the_skype_highlighting 4A C0 5E DE 7B C0 5E .(..@...!J.^.{.^ 00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .W.!.H. ...f..P. 00030: 22 38 23 6C 00 00 "8#l.. 40 00 80 06 21

Frame 5:

In this frame, you do not see anything special except for the server acknowledging the FIN that was transmitted from the client. 5 16.0281 BDC3 --> NTW3 TCP .A...., len: 0, seq: 1109646-1109646,

ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP

TCP: .A...., len:

0, seq: 1109646-1109646, ack: 8221824, win:28672, src:

139 dst: 2337 (NBT Session)

TCP: Source Port = 0x040D TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 1109646 (0x10EE8E) TCP: Acknowledgement Number = 8221824 (0x7D7480) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset

TCP: ......0. = No Synchronize TCP: .......0 = No Fin

TCP: Window = 28672 (0x7000) TCP: Checksum = 0xD5A3 TCP: Urgent Pointer = 0 (0x0) TCP: Frame Padding

00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 begin_of_the_skype_highlighting 84 08 00 45 00 end_of_the_skype_highlighting ...".9........E. 00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .(....?.k..^.W.^ 00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 .{.H.!.f... ..P. 00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p...........

Frame 6:

After receiving the FIN from the client computer, the server will ACK. Even though TCP has established connections between the two computers, the connections are still independent of one another. Therefore, the server must also transmit a FIN (TCP .A...F) to the client. 6 17.0085 BDC3 --> NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP

TCP: .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session)

TCP: Source Port = 0x0548 TCP: Destination Port = 0x0921 TCP: Sequence Number = 1109646 (0x10EE8E) TCP: Acknowledgement Number = 8221824 (0x7D7480) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x11 : .A...F

TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......1 = No more data from sender

TCP: Window = 28672 (0x7000) TCP: Checksum = 0xD5A2 TCP: Urgent Pointer = 0 (0x0) TCP: Frame Padding

00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 begin_of_the_skype_highlighting 84 08 00 45 00 end_of_the_skype_highlighting ...".9........E.

00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .(....?.k..^.W.^ 00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .{.H.!.f... ..P. 00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p...........

Frame 7:

The client responds in the same format as the server, by ACKing the server's FIN and incrementing the sequence number by 1. 7 17.0085 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack: 1109647, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...., len:

0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:

2337 dst: 139 (NBT Session)

TCP: Source Port = 0x0921 TCP: Destination Port = 0x0548 TCP: Sequence Number = 8221824 (0x7D7480) TCP: Acknowledgement Number = 1109647 (0x10EE8F) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data

TCP: ...1.... = Acknowledgement field significant TCP: ....0... = No Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238) TCP: Checksum = 0x236B TCP: Urgent Pointer = 0 (0x0)

00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E. 00010: 00 28 BA F5 40 00 80 06 02 begin_of_the_skype_highlighting end_of_the_skype_highlighting 4A C0 5E DE 7B C0 5E .(..@....J.^.{.^ 00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .W.!.H. ...f..P. 00030: 22 38 23 6B 00 00 "8#k.. 40 00 80 06 02

The client ACKing the FIN notification from the server identifies a graceful close of a TCP connection.

This article covers some basic concepts and tips needed for reading TCP/IP traces.

TCP Flags
A, ACK- (Acknowledge) The receiver will send an ACK that equals the senders sequence number plus the Len, or amount of data, at the TCP layer.

SYN, and FIN flags count as 1 byte. The ACK can also be thought of as the sequence number of the next octet the receiver expects to receive.

S, SYN- Synchronize is used during session setup to agree on initial sequence numbers. Sequence numbers are random.

F, FIN- Finish is used during a graceful session close to show that the sender has no more data to send.

R, RST- Reset is an instantaneous abort in both directions (abnormal session disconnection).

P, PSH- Push forces data delivery without waiting for buffers to fill. This is used for interactive traffic. The data will also be delivered to the application on the receiving end with out buffering.

U, URG- Urgent- Data is sent out of band. Example of 3 Way Hand Shake -------------------------------------------------------------Time Dst IP Src IP Protocol Description ....S., len: 4, seq:

20.862 157.57.24.193 157.57.11.169 TCP 346564214, ack: 0, win: 8192,

20.866 157.57.11.169 157.57.24.193 TCP 339000739, ack: 346564215, win: 8760,

.A..S., len:

4, seq:

20.866 157.57.24.193 157.57.11.169 TCP 346564215, ack: 339000740, win: 8760,

.A...., len:

0, seq:

Example of Graceful Close (Modified 3 Way Hand Shake)

Time

Dst IP

Src IP

Protocol

Description .A...F, len: 0, seq:

39.295 157.57.11.169 157.57.24.193 TCP 339000917, ack: 346564257, win: 8718,

39.295 157.57.24.193 157.57.11.169 TCP 346564257, ack: 339000918, win: 8583,

.A...., len:

0, seq:

39.298 157.57.24.193 157.57.11.169 TCP 346564257, ack: 339000918, win: 8583,

.A...F, len:

0, seq:

39.300 157.57.11.169 157.57.24.193 TCP 339000918, ack: 346564258, win: 8718,

.A...., len:

0, seq:

In the above two traces, transmission control protocol (TCP) is the highest layer protocol, so the relevant session information can be read from the summary line of the trace. If there is a higher

layer protocol (NBT, SMB, Telnet, FTP, etc.), you will have to look in the packet for the TCP flags, acks and sequence numbers. Back to the top

Re-transmission Behavior
(from "TCP/IP Implementation Details")

TCP starts a re-transmission timer when each outbound segment is handed down to IP. If no acknowledgment has been received for the data in a given segment before the timer expires, then the segment is retransmitted, up to the TcpMaxDataRetransmissions times. The default value for this parameter is 5.

The re-transmission timer is initialized to 3 seconds when a TCP connection is established; however it is adjusted "on the fly" to match the characteristics of the connection using Smoothed Round Trip Time (SRTT) calculations as described in RFC793. The timer for a given segment is doubled after each re-transmission of that segment. Using this algorithm, TCP tunes itself to the "normal" delay of a connection. TCP connections over high-delay links will take much longer to time out than those over low- delay links.

The following trace clip shows the re-transmission algorithm for two hosts connected over Ethernet on the same subnet. An FTP file transfer was in progress, when the receiving host was disconnected from the network. Since the SRTT for this connection was very small, the first retransmission was sent after about one-half second. The timer was then doubled for each of the re-transmissions that followed. After the fifth re-transmission, the timer is once again doubled, and if no acknowledgment is received before it expires, then the transfer is aborted. delta source ip dest ip pro flags description

-------------------------------------------------------------0.000 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

0.521 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

1.001 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

2.003 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

4.007 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

8.130 10.57.10.32 10.57.9.138 TCP .A...., len: 1460, seq: 8043781, ack: 8153124, win: 8760

After computer "X's" retries are exhausted, you may not see a "Reset" right away. If computer "Y" finally responds, computer "X" may then reset the connection. Back to the top

Sliding Windows
During the handshake, the send window size is set to the other host's receive window. The window size is a buffer and is the amount of data the sender can send and the receiver can receive without an ack. The "window" can slide forward after that packet is acknowledged.

With a receive window of 8760, the sender may send 8760 bytes before receiving an ack. The receiver could ack every packet, every other packet or the entire 8760 depending on the IP stack and timing. (See Delayed Ack Timer, and Retransmit timer) Windows NT will ack every other packet. If the packets are coming extremely fast, you may see Windows NT ack more than 2 packets. If the PUSH bit set, data will be delivered up to the application right away, but the ack may still be delayed.

The sequence number in frame 51 is 349349990. The ack in frame 57 is 349358750. This is the sequence number from frame 51 plus the amount of data received in frames 51 through 56 (6 frames x 1460 =8760) . Also, the ack 349358750 is the sequence number of the next packet that the host expects to receive. Frame Time Src Other Addr Dst Other Addr Protocol Description

--------------------------------------------------------------------50 3.923 157.57.11.169 157.57.24.193 TCP .A...., len:

0, seq: 356870796, ack: 349349990, win: 8760,

51

3.924 157.57.24.193 157.57.11.169 FTP

Data Transfer To

Client, Port = 1636, size 1460 + TCP: .A...., len: 1460, seq: 349349990, ack: 356870796, win: 8760, src: 20 dst: 1636

52

3.940 157.57.24.193 157.57.11.169 FTP

Data Transfer To

Client, Port = 1636, size 1460

53

3.941 157.57.24.193 157.57.11.169 FTP

Data Transfer To

Client, Port = 1636, size 1460

54

3.943 157.57.24.193 157.57.11.169 FTP

Data Transfer To

Client, Port = 1636, size 1460

55

3.944 157.57.24.193 157.57.11.169 FTP

Data Transfer To

Client, Port = 1636, size 1460

56

3.946 157.57.24.193 157.57.11.169 FTP

Data Transfer To

Client, Port = 1636, size 1460

57

3.947 157.57.11.169 157.57.24.193 TCP

.A...., len:

0, seq: 356870796, ack: 349358750, win: 4096,

The window size is also used for flow control. If a host is advertising a smaller window size when its buffers are filling, or a window size of 0 if it can not receive data at all. In frame 50 above, the host is advertising a window size of 8760 and in frame 57 it has been dropped to 4096. Back to the top

Ports, Connections, and Endpoints

Port numbers define the ultimate destination within a computer. Connections are identified by a pair of endpoints. An Endpoint is the (host, port). Ex. (199.199.40, 21) Back to the top

Port Numbers

The port numbers are divided into three ranges: the Well-Known Ports,the Registered Ports, and the Dynamic and/or Private Ports. The Well-Known Ports are those from 0 through 1023.The Registered Ports are those from 1024 through 49151. The Dynamic and/or Private Ports are those from 49152 through 65535.

Well-Known Ports are assigned by Internet Assigned Numbers Authority (IANA) and should only be used by System Processes or by programs executed by priviledged users. An example of this type of port is 80/TCP and 80/UDP. These ports are priviledged and reserved for use by the HTTP protocol.

Registered Ports are listed by the IANA and on most systems can be used by ordinary user processes or programs executed by ordinary users. An example of this type of port is 1723/ TCP and 1723/UDP. Although these ports can be used by other processes they are generally accepted as the connection control port for Point To Point Tunnelling Protocol (PPTP).

Dynamic or Private Ports can be used by any process or user. They are unrestricted.

IANA maintains a list of ports on their Web site at: http://www.iana.org/assignments/port-numbers (http://www.iana.org/assignments/port-numbers) Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this thirdparty contact information. Back to the top

Trace Reading Suggestions

Follow a session using source and destination IP address and Port numbers. If you find a Reset, focus on the sequence numbers and acks that proceed it. Use a calculator to see what ack is corresponding to what data sent. Newer versions of NetMon will do the calculations for you. Is the sender doing retries? Note the number of retries and the time elapsed. The default number of retries is 5. Is the receiver asking for a missed frame by ACKing a previous sequence number? Did the sender back up and resend the previous packet? A Reset can be caused by

time-outs at the TCP layer or by time outs of higher layer protocols. Resets originating at the TCP layer should be easy to read from the trace. It may be more difficult to determine the cause of Resets originating from higher layer protocols.

For example, a Server Message Block (SMB) read may time out in 45 seconds and cause a Reset of the session even though communications are slow but working at the TCP layer. The trace may only narrow down what component is at fault. From there you may need to use other troubleshooting methods to determine the cause.

To see TCP sequencing when higher-level protocols are present, start Network Monitor and perform the following steps: 1. 2. 3. 4. 5. 6. 7. 8. 9. Click Capture, and then choose Display Captured Data. Click Display, and then choose Options. Select Auto (Based on protocols in display filter), and then click OK. Click Display, and then choose Filter. Double-click Protocol=Any. Click the Protocol tab, and then click Disable All. In the Disabled Protocols list box, choose TCP. Click Enabled, then click OK. Click OK.

TCP Connection States and Netstat Output

This article describes TCP connection states and how to read Netstat (NETSTAT.EXE) output. Before data transfer takes place in TCP, a connection must be established. TCP employs a three-way handshake (the details of this can be found in RFC793, Chapter 3: "Functional Specification").

TCP Connection States

Following is a brief explanation of this handshake. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. Note that this notation does not reflect Client/Server relationships as an architectural principal.

1. Connection Establishment

2. The client sends a SYN message which contains the server's port and the client's Initial Sequence Number (ISN) to the server (active open). The server sends back its own SYN and ACK (which consists of the client's ISN + 1). The Client sends an ACK (which consists of the server's ISN + 1). 3. Connection Tear-down (modified three way handshake). 4. The client sends a FIN (active close). This is a now a half-closed connection. The client no longer sends data, but is still able to receive data from the server. Upon receiving this FIN, the server enters a passive close state. The server sends an ACK (which is the clients FIN sequence + 1) The server sends its own FIN. The client sends an ACK (which is server's FIN sequence + 1). Upon receiving this ACK, the server closes the connection. A half-closed connection can be used to terminate sending data while sill receiving data. Socket applications can call shutdown with the second argument set to 1 to enter this state. Back to the top

Netstat Output
The above TCP connection states can be monitored in a network trace under the TCP flags. It is also possible to determine the status of the connection by running the Netstat utility and looking at the State column. Netstat is shipped with Windows NT, Windows 95, and TCP/IP-32 for Windows for Workgroups.

State explanations as shown in Netstat: State Explanation ------------ --------------------------------------------------------

SYN_SEND Indicates active open.

SYN_RECEIVED Server just received SYN from the client.

ESTABLISHED Client received server's SYN and session is established.

LISTEN Server is ready to accept connection.

NOTE: See documentation for listen() socket call. TCP sockets in listening state are not shown this is a limitation of NETSTAT. For additional information, please see the following article in the Microsoft Knowledge Base: 134404 (http://support.microsoft.com/kb/134404/EN-US/ ) NETSTAT.EXE Does Not Show TCP Listen Sockets FIN_WAIT_1 Indicates active close.

TIMED_WAIT Client enters this state after active close.

CLOSE_WAIT Indicates passive close. Server just received first FIN from a client.

FIN_WAIT_2 Client just received acknowledgment of its first FIN from the server.

LAST_ACK Server is in this state when it sends its own FIN.

CLOSED Server received ACK from client and connection is closed. As an example, consider the following scenario:

A socket application has been terminated, but Netstat reports the socket in a CLOSE_WAIT

state. This could indicate that the client properly closed the connection (FIN has been sent), but the server still has its socket open. This could be the result of one instance (among all threads or processes) of the socket not being closed.

NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). MSL is specified to be 2 minutes. So, a socket could be in a TIME_WAIT state for as long as 4 minutes. Some systems implement different values (less than 2 minutes) for the MSL.

Additional references: "Internetworking with TCP/IP, Volume 1" by Douglas Comer "TCP/IP Illustrated, Volume 1" by Richard Stevens. "Computer Networks" by Andrew Tanenbaum

A TCP Session That Ends with a TCP Reset May Not Indicate a Problem
A TCP session that ends with a TCP reset may not indicate a problem. Sometimes TCP resets (RST) indicate a network problem, but there are cases in which a TCP reset is a good thing.

Because Transmission Control Protocol (TCP) is connection-oriented, most information technology (IT) professionals prefer to see the exchange of FIN ACK packets to perform session teardown. However, in some instances application developers elect to issue a Reset instead to free up resources more quickly for waiting users. A Reset may also be observed in instances where the destination TCP host is not running the desired service, or if the destination port is unavailable. Both of these methods of session teardown are compliant with RFC 1122: 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 A TCP connection may terminate in two ways: (1) the normal TCP close sequence using a FIN handshake, and (2) an "abort" in which one or more RST segments are sent and the connection state is

immediately discarded. For additional information, click the article number below to view the article in the Microsoft Knowledge Base: 172983 (http://support.microsoft.com/kb/172983/EN-US/ ) Explanation of the Three-Way Handshake via TCP/IP

Debugging sSL handshake failure using network monitor a scenario

In one of my earlier post I explained how to use Microsoft Network Monitor to debug a networking problem. Network trace tools arent very useful in debugging problems when the channel is secured (HTTPS) and you need to view the data to make your conclusions. However you can still debug SSL handshake failures using network monitor. Heres a scenario. A client (Not browser) is trying to connect to a IIS web server by sending its client certificate to post some data. However, the IIS machine always rejects the authentication. The first step was to take a network trace as usual. For instructions on how to capture simultaneous traces, see this post Analyzing the network trace: I filtered the traffic by the keyword SSL. In the display filter tab, type SSL and click on Apply button. Here are some of the frames the we picked from the capture: Fra me 7 Src Dst Proto col SSL Description

Clie nt Serv er Serv er Serv er Serv er Serv er Serv er

Serv er

SSL:SSLv2RecordLayer, ClientHello(0x01)

Clien SSL t Clien SSL t Clien SSL t Clien SSL t Clien SSL t Clien SSL t

SSL: Server Hello. Certificate.

12

SSL:Continued Data: 1460 Bytes

13

SSL:Continued Data: 1460 Bytes

18

SSL:Continued Data: 1460 Bytes

22

SSL:Continued Data: 1460 Bytes

27

SSL: Encrypted Handshake Message.

30

Clie nt Serv er

Serv er

SSL

SSL: Certificate. Client Key Exchange. Change Cipher Spec. Encrypted Handshake Message. SSL: Encrypted Alert.

32

Clien SSL t

During SSL connection negotiation process, the client and server can mutually exchange certificates for authentication. The client authentication can be optional. To understand more about how the SSL negotiation takes place, please see these Microsoft KBs Description of the Secure Sockets Layer (SSL) Handshake Description of the Server Authentication Process During the SSL Handshake Essentially, what is going on here can be summarized as: 1. The client makes a hello request in Frame 7 2. The server responds with its certificate and then continued bytes from the server certificate. 3. The client then sends an "Encrypted handshake message" 4. The client then sends its certificate with Client Key exchange and also indicates a change of cipher spec. 5. In frame 32, we can see an encrypted alert! While performing any type of debugging, we need to follow the data; we need to look for something that is interesting. In this case an alert from the server is being sent. So we looked at what this alert is. Since our interesting frame is 32, we looked more at the headers and the details in the frame. Here is the frame in detail Frame: Number = 32, Captured Frame Length = 61, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[MAC Address],SourceAddress:[Source MAC Address] + Ipv4: Src = ServerIP, Dest = ClientIP, Next Protocol = TCP, Packet ID = 5022, Total IP Length = 47 + Tcp: Flags=...AP..., SrcPort=5443, DstPort=1100, PayloadLen=7, Seq=2764379044 2764379051, Ack=3896915131, Win=64240 (scale factor 0x0) = 64240 - Ssl: Encrypted Alert. - TlsRecordLayer: ContentType: Encrypted Alert - Version: TLS 1.0 Major: 3 (0x3) Minor: 1 (0x1) Length: 2 (0x2) EncryptedData: Binary Large Object (2 Bytes) Here is the handshake data in Hex (This data isn't encrypted yet because the handshake is still in progress) 00 1E 68 0F 3E 80 00 30 48 7E 1B 90 08 00 45 00 00 2F 13 9E 40 00 3D 06 D2 0E 0A F4 40 0F 0A 33 02 E7 15 43 04 4C A4 C5 13 A4 E8 46 34 BB 50 18 FA F0 2B B8 00 00 15 03 01 00 02 02 2A

We can conclude a lot from this frame. We know that this is an ethernet packet. The TCP flags set are AP, which means transfer data to the end application on the client without buffering at the TCP level, the communication port on the server is 5443, the client port is 1100, the window size for data transmission is 64240 bytes and so forth. The most interesting set of data is the TLS record layer It shows the major and minor versions in use after negotiation and the length of the data, which is 2 bytes. This data is encrypted. So heres the trick now. This is an encrypted alert and RFC defines the alert descriptions. You can find it here for TLS 1.0 (Transport layer security) Take the hex value of the 2 bytes of this message, which is 2A (The last 2 values, all values before this are headers in hex and we can ignore that because network monitor already gave us that information) Using Windows calculator, convert hex 2A into decimal. We get: 42. Now, lets go look at the TLS 1.0 RFC to find out what what decimal value 42 represents for Alert Description. You can search for AlertDescription on the page. You should get: decompression_failure(30), handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction(60), protocol_version(70), insufficient_security(71), internal_error(80), user_canceled(90), no_renegotiation(100), (255) } AlertDescription; Thus, we can see that 42 translates to bad_certificate. So we can say that the client sent a bad certificate to the server and therefore the server rejected the connection request. Armed with this information, we checked the client certificate in the certificate store and indeed, we had a bad certificate. Replacing it with a good certificate fixed the problem! Software has some a long way and enabled people around the world to do many things. It has also made our lives so much easier. However these new capabilities have also created new problems and the answers to those problems are software tools which are excellent utilities for debugging these problems. I want to once again thank all those developers who made these tools, continue to improve and build new tools. It makes the job of a support professional much easier and helps a lot of customers resolve complex problems. Thank you!

Using Microsoft network monitor to track down networking problems

There are a lot of software tools provided by Microsoft and written by other companies that really make the job of a support engineer easy. Without software tools, it is extremely difficult to track down software problems. Mark Russinovich is famous for the Windows tools he has written and they are widely used by Microsoft support teams to help debug various customer issues. Microsoft also provides a lot of software tools. In the IIS support group, we deal with HTTP failures that are a result of networking problems. Once we isolate it, the next thing to do is get simultaneous network traffic captures from the client and the server. That way we can see how the traffic flows between client and server and draw good conclusions on where the problem might be. There are two tools that can do this job and both are extremely good & very popular tools. Microsoft Network Monitor & Wireshark are a couple of tools that we use. You can download Microsoft Network Monitor from the Microsoft Download Center and Wireshark from Wireshark.org For a quick start on reading network traces using Network Monitor, please see this Microsoft article: Basics of Reading TCP/IP traces Recently we used Network Monitor to resolve a problem An ASP.net web page streams files to clients using Response.WriteFile method. All other pages work just fine, however when sending the file, the clients end up getting Page cannot be displayed. I had earlier written this blog post about this error, but which was for different reason. In that case, no web pages would work but in this case only the file download page failed. One of the first things we do is isolate the problem area. Isolating the problem helps you focus on a specific part rather than looking at too many variables & possibilities. In this case we wanted to isolate if this an application related problem or just networking. We could never reproduce the problem by browsing the page from the web server console. We always had success from the server console. By browsing the page from the server console, we take the network out of the equation. Because we had success in this case, it was determined that this problem is caused by something going on in the networking layer. The next thing to do is get data about the underlying traffic looks during the failure. Remember that you always need to get good data to draw useful conclusions. Without good data, we are just shooting in the dark. In this case we captured simultaneous network traces. Please refer to this post for steps to take simultaneous network traces. Heres how we went about analyzing the traces. Opened the trace in Microsoft Network Monitor The next thing to do is filter the traffic we are interested in. Take a moment to look at the user interface items of Network Monitor that I highlighted in red circles.

The Display Filter tab allows you to specify keywords or expressions that will help you filter traffic. For Eg. if you want to see only HTTP traffic, you can type http in the Display Filter text area and click on Apply button. In this particular case I not only wanted to see HTTP traffic but also the TCP frames (between the web server this the client) and therefore I used a different filter, which was: (tcp.SrcPort == 3117 && tcp.DstPort == 80) || (tcp.SrcPort == 80 && tcp.DstPort == 3117) So how did I figure the port numbers? HTTP port number on a web server is almost always 80 unless the URL in the browser contained the port number like http://localhost:8080. So that is how I got the DstPort value. Next, I wanted to get the SrcPort. I filtered using http and looked for a frame with the URL that we used in reproducing the problem. Then selected that frame and looked at the Frame Details pane to get the SrcPort & DstPort values. Compare the traces from the client & server captures using Frame Summary Window.

This is where it gets a bit tricky for people who are not familiar with reading traces. For most its just a lot of data and numbers, but let me help you read these traces. Pay special attention to the coloring as they are important. Client Capture Fra me 182 Time Src IP CLI ENT SER VER CLI ENT CLI ENT CLI ENT Dst IP SER VER CLIE NT SER VER SER VER SER VER Prot ocol TCP Description

11:38:1 6.449 11:38:1 6.465 11:38:1 6.465 11:38:1 6.465 11:38:1 6.465

TCP:Flags=......S., SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=1608257832 TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3131352675, Ack=1608257833 TCP:Flags=...A...., SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=1608257833, Ack=3131352676 HTTP:Request, POST /Server/AppFolder/SendFile.aspx

183

TCP

184

TCP

185

HTT P TCP

186

TCP:[Continuation to #185]Flags=...AP..., SrcPort=3117, DstPort=HTTP(80), PayloadLen=1095, Seq=1608259213 1608260308 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3131352676, Ack=1608259213 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3131352676, Ack=1608260308 TCP:Flags=...A...F, SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3131352676, Ack=1608260308 TCP:Flags=...A...., SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=1608260308, Ack=3131352677 TCP:Flags=...A...F, SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=1608260308, Ack=3131352677 TCP:[Segment Lost]Flags=...A...., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3131352677, Ack=1608260309

188

11:38:1 6.496 11:38:1 6.496 11:39:4 6.509 11:39:4 6.509 11:39:4 6.509 11:39:4 6.525

SER VER SER VER SER VER CLI ENT CLI ENT SER VER

CLIE NT CLIE NT CLIE NT SER VER SER VER CLIE NT

TCP

189

TCP

175 1 175 2 175 3 175 4

TCP

TCP

TCP

TCP

Server Capture Fra me 278 9 Time Src IP CLI ENT Dst IP SER VER Prot ocol TCP Description

11:28: 18.442

TCP:Flags=......S., SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=2256040559, Ack=0

279 0 279 1 279 2 279 3

11:28: 18.442 11:28: 18.442 11:28: 18.442 11:28: 18.442

SER VER CLI ENT CLI ENT CLI ENT

CLIE NT SER VER SER VER SER VER

TCP

TCP:Flags=...A..S., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3177618710, Ack=2256040560 TCP:Flags=...A...., SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=2256040560, Ack=3177618711 HTTP:Request, POST /Server/AppFolder/SendFile.aspx

TCP

HTT P TCP

TCP:[Continuation to #2792]Flags=...AP..., SrcPort=3117, DstPort=HTTP(80), PayloadLen=12, Seq=2256041928 2256041940, Ack=3177618711 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3177618711, Ack=2256041940 HTTP:HTTP Payload, URL: /Server/AppFolder/SendFile.aspx

279 4 279 5 285 9 644 7 644 8

11:28: 18.442 11:28: 18.442 11:28: 18.563 11:29: 48.425 11:29: 48.425

SER VER CLI ENT SER VER CLI ENT SER VER

CLIE NT SER VER CLIE NT SER VER CLIE NT

TCP

HTT P TCP

TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3177618711, Ack=2256043035 TCP:Flags=...A...F, SrcPort=3117, DstPort=HTTP(80), PayloadLen=0, Seq=2256043035, Ack=3177618711 TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=3117, PayloadLen=0, Seq=3177618711, Ack=2256043036

TCP

TCP

Observation 1. If you compare the sequence (Seq) numbers (highlighted in red) for each frame in both captures, they are different. So what does this mean? It means, someone in between the client and server changed the sequence numbers. In a normal capture, the sequence numbers will be the same in both captures for each corresponding frame.

2. 3. 4. The value for PayLoadLen (highlighted in yellow) are different in the server and client captures.
What does this mean? It would indicate that the packets were split by some device/program in between.

5. 6. 7. The client capture indicates that the server closed the connection by sending a FIN (see frame
1751 in the client capture). However, you do not see this in the server capture. The server never set the FIN TCP flag! Summary & Conclusion With this data, it is clear that there is a middle man, perhaps a device or software in between the client and server that isnt handling the data flow correctly. The next step is to look at the networking infrastructure or get a network administrator to look at the devices that are in between the clients and IIS web server and isolate the offending device.