Está en la página 1de 31

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

0....1.. = No Push function TCP: .A..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 : .S.0.. = Synchronize sequence numbers TCP: ...... = Acknowledgement field significant TCP: ..1....0..... TCP: .... = No Reset TCP: .. = No urgent data 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) .

k 00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ..L... 00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8..[. 00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .... src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP TCP: ..}t`. len: 0..`......A. thus the three-way handshake. ack: 1109646. The client's acknowledgment of the server's request for synchronization completes the process of establishing a reliable connection. Frame 3: In the third frame. win: 8760. 3 2.A. The client uses the same algorithm the server implemented in providing an acknowledgement number.....-...787 NTW3 --> BDC3 TCP .. seq: 8221823-8221823. len: 0.E... In this segment. seq: 8221823-8221823.. src: 1037 dst: 139 (NBT Session) TCP: Source Port = 0x040D ... ack: 1109646.).....k.A...... win: 8760.@. the client sends an ACK on this segment (TCP ....`.... the client is acknowledging the request from the server for synchronization.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 .

...@...........A..k 00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .k.. .. = No Synchronize TCP: .`.. TCP: ...`..... 00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B ..0. = Acknowledgement field significant TCP: ..O...0.... = No urgent data TCP: .......(...........0.. = No Push function TCP: ..P..0..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 : ...}t..1.E...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 .... = No Reset TCP: .

First. the termination of this reliable connection will necessitate the transmission of four packets. when the FIN parameter is set..00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8. each direction must be terminated independently. seq: 8221823-8221823.. 4 16. data can be flowing in each direction independent of the other).. ack:3462835714 begin_of_the_skype_highlighting 3462835714 end_of_the_skype_highlighting. win: 8760. it will inform the server that it has no more data to send. you see the client sending a FIN that is accompanied by an ACK (TCP . Because a TCP connection is full duplex (that is.0279 NTW3 --> BDC3 TCP . len: 0. win: 8760. Second. the ACK is essential in identifying the specific connection they have established.A. src: 1037 dst: 139 (NBT Session) TCP: Source Port = 0x040D TCP: Destination Port = NETBIOS Session Service ...F. len: 0...F). src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP TCP: . This segment has two basic functions.A. ack: 1109646.A. Frame 4: In this session of frames.F.. Back to the top Terminating a Connection Although the three-way handshake only requires three packets to be transmitted over our networked media.. seq: 8221823-8221823.

...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 ..!J.0.". 40 00 80 06 21 ... = No Push function TCP: .9. = Acknowledgement field significant TCP: ..F TCP: ...{..TCP: Sequence Number = 8221823 (0x7D747F) TCP: Acknowledgement Number = 1109646 (0x10EE8E) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x11 : .G..H..... = No urgent data TCP: ..!.0...f.0.^.1.......P.W. 00030: 22 38 23 6C 00 00 "8#l.^ 00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .....A.... = No Synchronize TCP: .....X..0..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 .... .(.. = No Reset TCP: . ...@.

..... seq: 1109646-1109646.. = No Reset .1......... len: 0. src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP TCP: . seq: 1109646-1109646.. 5 16.. you do not see anything special except for the server acknowledging the FIN that was transmitted from the client.. len: 0. win:28672. ack: 8221824..0281 BDC3 --> NTW3 TCP . win:28672.0.. TCP: ....A..Frame 5: In this frame. = No urgent data TCP: ..A.0.. 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 : . ack: 8221824.A... = No Push function TCP: ..0... = Acknowledgement field significant TCP: ..

00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p.(.0085 BDC3 --> NTW3 TCP ... ack: 8221824.". Even though TCP has established connections between the two computers.{. len: 0... seq: 1109646-1109646.. Frame 6: After receiving the FIN from the client computer....f... src: 139 dst: 2337 (NBT Session) .F..^. 00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .0.F) to the client.. the connections are still independent of one another.... seq: 1109646-1109646.E...A.. win:28672. the server will ACK...?..k. ....!....A. win:28672.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 ...P. src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP TCP: .F... Therefore.. = No Synchronize TCP: .^ 00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 ..H. 6 17..TCP: .....A.W.. ack: 8221824.9.. the server must also transmit a FIN (TCP . len: 0....

= No Push function TCP: . ..E..... = 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 ..."...........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 : ..0..... = No urgent data TCP: .0..1........ = No Reset TCP: .....F TCP: .0...9..0..A... = Acknowledgement field significant TCP: .

....k. 00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p.. 7 17.!.(.^ 00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .. . TCP: ... len: 0.{........ = No urgent data . src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP TCP: .. 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 : . ack: 1109647.0.... win: 8760.W...A. seq: 8221824-8221824. by ACKing the server's FIN and incrementing the sequence number by 1..^.. seq: 8221824-8221824..f.A....A..0085 NTW3 --> BDC3 TCP ...H. Frame 7: The client responds in the same format as the server...?.P.. len: 0. ack: 1109647.

.. .X.(.^. 00030: 22 38 23 6B 00 00 "8#k. = No Push function TCP: . TCP Flags A. 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 ....."....P.TCP: .0.(Acknowledge) The receiver will send an ACK that equals the senders sequence number plus the Len.^ 00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .1.@... .. = No Reset TCP: . ACK.!.... . or amount of data....G..0. 40 00 80 06 02 The client ACKing the FIN notification from the server identifies a graceful close of a TCP connection.{.9....f.. at the TCP layer....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 . This article covers some basic concepts and tips needed for reading TCP/IP traces.....0. = Acknowledgement field significant TCP: .W.J.E..H. = No Synchronize TCP: .......

URG. len: 4.11. PSH. RST..24.A.193 157.Finish is used during a graceful session close to show that the sender has no more data to send.866 157.Reset is an instantaneous abort in both directions (abnormal session disconnection).57. FIN... The ACK can also be thought of as the sequence number of the next octet the receiver expects to receive.862 157. P.169 TCP 346564214.57.Synchronize is used during session setup to agree on initial sequence numbers. Example of 3 Way Hand Shake -------------------------------------------------------------Time Dst IP Src IP Protocol Description . U. SYN.Data is sent out of band.S.Urgent.24. len: 4. seq: 20. F.Push forces data delivery without waiting for buffers to fill. ack: 346564215...11. win: 8192.193 TCP 339000739.SYN.57. Sequence numbers are random. The data will also be delivered to the application on the receiving end with out buffering. win: 8760. This is used for interactive traffic. ack: 0. S. 20. R.57.169 157.S. seq: . .. and FIN flags count as 1 byte.

57. len: 0. ...193 TCP 339000917.57.193 157.A.193 157.57.F.24.. len: 0. seq: 39. seq: In the above two traces. . len: 0.. win: 8760. If there is a higher ..A.20.57. so the relevant session information can be read from the summary line of the trace.169 TCP 346564257. ack: 339000740.11. transmission control protocol (TCP) is the highest layer protocol.193 157. .24.57.24..298 157..169 157. win: 8583.F..57. ack: 339000918..866 157.11.295 157.300 157. seq: 39...57.A.11.11. 39.169 157. seq: Example of Graceful Close (Modified 3 Way Hand Shake) Time Dst IP Src IP Protocol Description ..57.24.11.. win: 8718.169 TCP 346564257.A. len: 0. ..57.A. seq: 39.193 TCP 339000918..24.169 TCP 346564215. ack: 346564257. win: 8583.295 157.57. win: 8718. ack: 346564258.. len: 0. ack: 339000918.

57. FTP. The timer was then doubled for each of the re-transmissions that followed. If no acknowledgment has been received for the data in a given segment before the timer expires.57.A. the timer is once again doubled. you will have to look in the packet for the TCP flags. SMB. Telnet.32 10. 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. and if no acknowledgment is received before it expires. up to the TcpMaxDataRetransmissions times. seq: 8043781. the first retransmission was sent after about one-half second.10.9. delta source ip dest ip pro flags description -------------------------------------------------------------0.. 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. len: 1460.layer protocol (NBT. An FTP file transfer was in progress. The following trace clip shows the re-transmission algorithm for two hosts connected over Ethernet on the same subnet. then the transfer is aborted. ack: 8153124. when the receiving host was disconnected from the network.. TCP connections over high-delay links will take much longer to time out than those over low.138 TCP .. Using this algorithm.). win: 8760 . etc. The re-transmission timer is initialized to 3 seconds when a TCP connection is established. TCP tunes itself to the "normal" delay of a connection.000 10. then the segment is retransmitted.delay links. The default value for this parameter is 5. Since the SRTT for this connection was very small. After the fifth re-transmission. acks and sequence numbers.. The timer for a given segment is doubled after each re-transmission of that segment.

A.0.007 10. ack: 8153124. win: 8760 2.57. Back to the top Sliding Windows During the handshake. len: 1460.9..32 10.. The "window" can slide forward after that packet is acknowledged.. ack: 8153124.9.138 TCP .138 TCP . ack: 8153124. ack: 8153124.003 10. seq: 8043781..32 10.10. len: 1460.32 10.A..138 TCP . len: 1460.10....57. len: 1460.9. seq: 8043781. ack: 8153124.10. seq: 8043781..130 10. seq: 8043781.. The window size is a buffer and is the amount of data the sender can send and the receiver can receive without an ack. seq: 8043781.9.138 TCP .521 10.A.. win: 8760 After computer "X's" retries are exhausted.A.57.57.57.10. computer "X" may then reset the connection. If computer "Y" finally responds.57. .57..57.10... you may not see a "Reset" right away.32 10.57.. win: 8760 1.57.A.138 TCP .... len: 1460.32 10...9. win: 8760 4.001 10. the send window size is set to the other host's receive window. win: 8760 8.

57.193 157. size 1460 .193 157.24.57.. seq: 349349990.57. If the PUSH bit set. The ack in frame 57 is 349358750..57. seq: 356870796.923 157. size 1460 53 3.A. data will be delivered up to the application right away.193 TCP .. src: 20 dst: 1636 52 3.24.940 157..11. Port = 1636. 51 3. Port = 1636. Frame Time Src Other Addr Dst Other Addr Protocol Description --------------------------------------------------------------------50 3. win: 8760.57.With a receive window of 8760.941 157.57.11. the ack 349358750 is the sequence number of the next packet that the host expects to receive. The receiver could ack every packet..24.193 157.A. Also. (See Delayed Ack Timer.169 157. len: 0. win: 8760. ack: 356870796. len: 1460.924 157..11. you may see Windows NT ack more than 2 packets. but the ack may still be delayed. and Retransmit timer) Windows NT will ack every other packet.57. size 1460 + TCP: . If the packets are coming extremely fast.57. every other packet or the entire 8760 depending on the IP stack and timing.169 FTP Data Transfer To Client. the sender may send 8760 bytes before receiving an ack. This is the sequence number from frame 51 plus the amount of data received in frames 51 through 56 (6 frames x 1460 =8760) .169 FTP Data Transfer To Client.169 FTP Data Transfer To Client.24. ack: 349349990..11.. Port = 1636. The sequence number in frame 51 is 349349990.

Back to the top Ports.169 FTP Data Transfer To Client.57.169 157. Connections.57. or a window size of 0 if it can not receive data at all.54 3.944 157.193 157.A.169 FTP Data Transfer To Client. size 1460 56 3.193 157.193 TCP .57. port).24.. and Endpoints Port numbers define the ultimate destination within a computer. ack: 349358750.199. size 1460 55 3.11. seq: 356870796.11.11.193 157. The window size is also used for flow control.. the host is advertising a window size of 8760 and in frame 57 it has been dropped to 4096. An Endpoint is the (host. If a host is advertising a smaller window size when its buffers are filling.943 157.947 157. win: 4096.57. (199. 21) Back to the top Port Numbers .11. Connections are identified by a pair of endpoints.24.57.57. size 1460 57 3. Ex.40.. In frame 50 above. Port = 1636.24. Port = 1636.169 FTP Data Transfer To Client.946 157.24..57. Port = 1636.57. len: 0.

the Registered Ports. IANA maintains a list of ports on their Web site at: http://www. They are unrestricted. This contact information may change without notice. and the Dynamic and/or Private Ports.The port numbers are divided into three ranges: the Well-Known Ports. Registered Ports are listed by the IANA and on most systems can be used by ordinary user processes or programs executed by ordinary users. Microsoft does not guarantee the accuracy of this thirdparty contact information.iana. Dynamic or Private Ports can be used by any process or user. 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 .iana. Use a calculator to see what ack is corresponding to what data sent.The Registered Ports are those from 1024 through 49151. An example of this type of port is 1723/ TCP and 1723/UDP. focus on the sequence numbers and acks that proceed it. Is the sender doing retries? Note the number of retries and the time elapsed. The default number of retries is 5. The Well-Known Ports are those from 0 through 1023.org/assignments/port-numbers (http://www. These ports are priviledged and reserved for use by the HTTP protocol. 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). Newer versions of NetMon will do the calculations for you. The Dynamic and/or Private Ports are those from 49152 through 65535. If you find a Reset. 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.org/assignments/port-numbers) Microsoft provides third-party contact information to help you find technical support. Back to the top Trace Reading Suggestions Follow a session using source and destination IP address and Port numbers.

Select Auto (Based on protocols in display filter). Note that this notation does not reflect Client/Server relationships as an architectural principal. TCP employs a three-way handshake (the details of this can be found in RFC793.time-outs at the TCP layer or by time outs of higher layer protocols. a connection must be established. Click Enabled. Resets originating at the TCP layer should be easy to read from the trace. choose TCP. Click OK. Double-click Protocol=Any. Click the Protocol tab. Connection Establishment . Chapter 3: "Functional Specification"). For example. and then choose Filter. In the Disabled Protocols list box. 5. 4. 1. 6. From there you may need to use other troubleshooting methods to determine the cause. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. To see TCP sequencing when higher-level protocols are present. TCP Connection States Following is a brief explanation of this handshake. 7. and then choose Options. It may be more difficult to determine the cause of Resets originating from higher layer protocols. 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. Click Display. TCP Connection States and Netstat Output This article describes TCP connection states and how to read Netstat (NETSTAT. 2. The trace may only narrow down what component is at fault. 9. 8. start Network Monitor and perform the following steps: 1. Click Display. and then choose Display Captured Data. Click Capture. and then click OK. then click OK. and then click Disable All. Before data transfer takes place in TCP. 3.EXE) output.

2. ○ The client sends a FIN (active close). It is also possible to determine the status of the connection by running the Netstat utility and looking at the State column. and TCP/IP-32 for Windows for Workgroups. Upon receiving this FIN. ○ The server sends back its own SYN and ACK (which consists of the client's ISN + 1). 3. 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 an ACK (which is the clients FIN sequence + 1) ○ The server sends its own FIN. the server closes the connection. the server enters a passive close state. ○ The Client sends an ACK (which consists of the server's ISN + 1). Netstat is shipped with Windows NT. 4. This is a now a half-closed connection. SYN_RECEIVED Server just received SYN from the client. The client no longer sends data. State explanations as shown in Netstat: State Explanation -----------. Connection Tear-down (modified three way handshake). Upon receiving this ACK. A half-closed connection can be used to terminate sending data while sill receiving data. but is still able to receive data from the server. Back to the top ○ Netstat Output The above TCP connection states can be monitored in a network trace under the TCP flags. Socket applications can call shutdown with the second argument set to 1 to enter this state.-------------------------------------------------------- SYN_SEND Indicates active open. . Windows 95. ○ The client sends an ACK (which is server's FIN sequence + 1).

LISTEN Server is ready to accept connection. please see the following article in the Microsoft Knowledge Base: 134404 (http://support. Server just received first FIN from a client. consider the following scenario: A socket application has been terminated. but Netstat reports the socket in a CLOSE_WAIT . LAST_ACK Server is in this state when it sends its own FIN. TIMED_WAIT Client enters this state after active close. NOTE: See documentation for listen() socket call.microsoft. CLOSED Server received ACK from client and connection is closed. FIN_WAIT_2 Client just received acknowledgment of its first FIN from the server.EXE Does Not Show TCP Listen Sockets FIN_WAIT_1 Indicates active close.com/kb/134404/EN-US/ ) NETSTAT. For additional information. TCP sockets in listening state are not shown this is a limitation of NETSTAT. As an example.ESTABLISHED Client received server's SYN and session is established. CLOSE_WAIT Indicates passive close.

MSL is specified to be 2 minutes. Additional references: ● ● ● "Internetworking with TCP/IP. Because Transmission Control Protocol (TCP) is connection-oriented.13 Closing a Connection: RFC-793 Section 3.2. "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.2. Volume 1" by Douglas Comer "TCP/IP Illustrated. most information technology (IT) professionals prefer to see the exchange of FIN ACK packets to perform session teardown. This could indicate that the client properly closed the connection (FIN has been sent). Sometimes TCP resets (RST) indicate a network problem. and (2) an "abort" in which one or more RST segments are sent and the connection state is . in some instances application developers elect to issue a Reset instead to free up resources more quickly for waiting users. or if the destination port is unavailable.5 A TCP connection may terminate in two ways: (1) the normal TCP close sequence using a FIN handshake. NOTE: It is normal to have a socket in the TIME_WAIT state for a long period of time. Both of these methods of session teardown are compliant with RFC 1122: 4. Some systems implement different values (less than 2 minutes) for the MSL. The time is specified in RFC793 as twice the Maximum Segment Lifetime (MSL). but the server still has its socket open. A Reset may also be observed in instances where the destination TCP host is not running the desired service. This could be the result of one instance (among all threads or processes) of the socket not being closed. Volume 1" by Richard Stevens. However. So. a socket could be in a TIME_WAIT state for as long as 4 minutes.state. but there are cases in which a TCP reset is a good thing.

see this post Analyzing the network trace: I filtered the traffic by the keyword SSL. Certificate. Here’s a scenario. click the article number below to view the article in the Microsoft Knowledge Base: 172983 (http://support. the IIS machine always rejects the authentication. type SSL and click on Apply button. For additional information. 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. 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. Network trace tools aren’t very useful in debugging problems when the channel is secured (HTTPS) and you need to view the data to make your conclusions.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. However. In the display filter tab. However you can still debug SSL handshake failures using network monitor. The first step was to take a network trace as usual. ClientHello(0x01) 9 Clien SSL t Clien SSL t Clien SSL t Clien SSL t Clien SSL t Clien SSL t SSL: Server Hello. For instructions on how to capture simultaneous traces.microsoft. A client (Not browser) is trying to connect to a IIS web server by sending its client certificate to post some data. .immediately discarded.

please see these Microsoft KBs Description of the Secure Sockets Layer (SSL) Handshake Description of the Server Authentication Process During the SSL Handshake Essentially.DestinationAddress:[MAC Address]. SrcPort=5443. 3. PayloadLen=7. So we looked at what this alert is. DstPort=1100.AP. The client then sends its certificate with Client Key exchange and also indicates a change of cipher spec. we need to follow the data. we need to look for something that is “interesting”. MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4). The client authentication can be optional. Seq=2764379044 2764379051. the client and server can mutually exchange certificates for authentication. 5. Dest = ClientIP. Ack=3896915131.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 .Ssl: Encrypted Alert. In frame 32.30 Clie nt Serv er Serv er SSL SSL: Certificate. what is going on here can be summarized as: 1. The client then sends an "Encrypted handshake message" 4. To understand more about how the SSL negotiation takes place.SourceAddress:[Source MAC Address] + Ipv4: Src = ServerIP. we can see an encrypted alert! While performing any type of debugging. Since our “interesting” frame is 32.. The server responds with its certificate and then continued bytes from the server certificate.Version: TLS 1. Here is the frame in detail Frame: Number = 32.. Next Protocol = TCP.. Win=64240 (scale factor 0x0) = 64240 . we looked more at the headers and the details in the frame. . In this case an “alert” from the server is being sent..TlsRecordLayer: ContentType: Encrypted Alert . Client Key Exchange. Total IP Length = 47 + Tcp: Flags=. The client makes a hello request in Frame 7 2. SSL: Encrypted Alert. 32 Clien SSL t During SSL connection negotiation process. Captured Frame Length = 61. Packet ID = 5022. Encrypted Handshake Message.. Change Cipher Spec.

we can see that 42 translates to bad_certificate. the window size for data transmission is 64240 bytes and so forth. You can find it here for TLS 1. decode_error(50). certificate_expired(45).0 (Transport layer security) Take the hex value of the 2 bytes of this message. It has also made our lives so much easier. I want to once again thank all those developers who made these tools. We get: 42. So here’s the trick now. 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. continue to improve and build new tools. certificate_unknown(46). handshake_failure(40). we checked the client certificate in the certificate store and indeed. The TCP flags set are AP. we had a bad certificate. You should get: decompression_failure(30). This is an encrypted alert and RFC defines the alert descriptions. decrypt_error(51). the client port is 1100. no_renegotiation(100).We can conclude a lot from this frame. certificate_revoked(44). Thus. Armed with this information. insufficient_security(71). bad_certificate(42). protocol_version(70). Thank you! . unknown_ca(48). You can search for “AlertDescription” on the page. illegal_parameter(47). We know that this is an ethernet packet. Now. 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. access_denied(49). which is 2 bytes.0 RFC to find out what what decimal value 42 represents for Alert Description. This data is encrypted. user_canceled(90). export_restriction(60). unsupported_certificate(43). (255) } AlertDescription. which is 2A (The last 2 values. So we can say that the client sent a bad certificate to the server and therefore the server rejected the connection request. It makes the job of a support professional much easier and helps a lot of customers resolve complex problems. all values before this are headers in hex and we can ignore that because network monitor already gave us that information) Using Windows calculator. 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. internal_error(80). let’s go look at the TLS 1. convert hex 2A into decimal. the communication port on the server is 5443. which means transfer data to the end application on the client without buffering at the TCP level.

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

The Display Filter tab allows you to specify keywords or expressions that will help you filter traffic.DstPort == 80) || (tcp. I filtered using http and looked for a frame with the URL that we used in reproducing the problem.SrcPort == 3117 && tcp. For Eg. which was: (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. Compare the traces from the client & server captures using Frame Summary Window.SrcPort == 80 && tcp. if you want to see only HTTP traffic. Next. 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. So that is how I got the DstPort value. I wanted to get the SrcPort. Then selected that frame and looked at the Frame Details pane to get the SrcPort & DstPort values. . you can type http in the Display Filter text area and click on Apply button.

... PayloadLen=0.. PayloadLen=0.F. but let me help you read these traces. DstPort=3117. DstPort=HTTP(80).. PayloadLen=0..A. DstPort=HTTP(80)... PayloadLen=0. DstPort=HTTP(80).. DstPort=3117.465 11:38:1 6. Seq=2256040559. Seq=1608260308. PayloadLen=0.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.A.... Ack=3131352677 TCP:Flags=.A.S.A. SrcPort=3117.509 11:39:4 6... PayloadLen=0.aspx 183 TCP 184 TCP 185 HTT P TCP 186 TCP:[Continuation to #185]Flags=.... Ack=1608257833 TCP:Flags=. Ack=1608260308 TCP:Flags=.. Ack=3131352677 TCP:[Segment Lost]Flags=.. SrcPort=3117.A.465 11:38:1 6.509 11:39:4 6. 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.S. Seq=3131352677.....442 TCP:Flags=. Seq=1608257832 TCP:Flags=...465 11:38:1 6....F. Seq=3131352675.AP. DstPort=HTTP(80). Pay special attention to the coloring as they are important..A.. Seq=1608260308. SrcPort=HTTP(80).. SrcPort=HTTP(80).. DstPort=3117.... SrcPort=HTTP(80). PayloadLen=1095... PayloadLen=0....496 11:39:4 6.A. Ack=0 ....496 11:38:1 6. SrcPort=HTTP(80). SrcPort=3117. Ack=1608260308 TCP:Flags=. DstPort=HTTP(80). DstPort=3117.. Seq=3131352676.. PayloadLen=0.. SrcPort=3117.. Ack=3131352676 HTTP:Request. SrcPort=3117. For most its just a lot of data and numbers.. SrcPort=3117.This is where it gets a bit tricky for people who are not familiar with reading traces. Seq=3131352676... Ack=1608260309 188 11:38:1 6. PayloadLen=0. DstPort=HTTP(80)... Seq=1608257833. Seq=3131352676. PayloadLen=0.509 11:39:4 6. Ack=1608259213 TCP:Flags=.465 TCP:Flags=.. Seq=1608259213 1608260308 TCP:Flags=... POST /Server/AppFolder/SendFile.A...449 11:38:1 6. SrcPort=HTTP(80).S. DstPort=3117...

the sequence numbers will be the same in both captures for each corresponding frame. DstPort=HTTP(80).aspx 279 4 279 5 285 9 644 7 644 8 11:28: 18. The value for PayLoadLen (highlighted in yellow) are different in the server and client captures.AP.. DstPort=HTTP(80). In a normal capture.A.279 0 279 1 279 2 279 3 11:28: 18. 6.S.aspx TCP HTT P TCP TCP:[Continuation to #2792]Flags=. Ack=3177618711 TCP:Flags=. Seq=3177618710.. 2.A. POST /Server/AppFolder/SendFile.. PayloadLen=0. . SrcPort=3117.563 11:29: 48. Seq=3177618711..... SrcPort=HTTP(80). Ack=3177618711 TCP:Flags=. 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.. SrcPort=HTTP(80)..425 11:29: 48. Seq=3177618711.. PayloadLen=12..442 SER VER CLI ENT CLI ENT CLI ENT CLIE NT SER VER SER VER SER VER TCP TCP:Flags=.. 7. DstPort=HTTP(80).442 11:28: 18.A. DstPort=3117... 3.. you do not see this in the server capture.A. Seq=2256043035. PayloadLen=0. SrcPort=3117.442 11:28: 18. SrcPort=HTTP(80).. DstPort=3117.A.. The client capture indicates that the server closed the connection by sending a “FIN” (see frame 1751 in the client capture).442 11:28: 18. The server never set the FIN TCP flag! Summary & Conclusion With this data.. Seq=2256041928 2256041940.. Ack=2256043036 TCP TCP Observation 1.... Seq=3177618711.. it is clear that there is a “middle man”. PayloadLen=0.. What does this mean? It would indicate that the packets were split – by some device/program in between. Ack=2256041940 HTTP:HTTP Payload. perhaps a device or software in between the client and server that isn’t handling the data flow correctly. DstPort=3117. DstPort=3117.442 11:28: 18..A.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=. If you compare the sequence (Seq) numbers (highlighted in red) for each frame in both captures. However. PayloadLen=0. SrcPort=HTTP(80).. PayloadLen=0.. Ack=2256040560 TCP:Flags=. Seq=2256040560. 4. PayloadLen=0. URL: /Server/AppFolder/SendFile. Ack=2256043035 TCP:Flags=.. they are different.F.... someone in between the client and server changed the sequence numbers..442 11:28: 18.... Ack=3177618711 HTTP:Request... So what does this mean? It means. SrcPort=3117. 5.