

This believed to be a software bug the initial acknowledgement number of a session should always be zero, as you can see from inspecting the hex dump of the packet.) Packet #2 (Note: The version of Wireshark used for this demonstration, 1.2.7, shows the acknowledgement number as an apparently random number. Likewise, the acknowledgement number is also zero, as there is not yet a complementary side of the conversation to acknowledge. Packet #1Įach side of a TCP session starts out with a (relative) sequence number of zero. We can use this flow graph to better understand how sequence and acknowledgement numbers work. Selecting a row in this column also highlights the corresponding packet in the main window. The column at right lists the relative sequence and acknowledgement numbers in decimal. The left column indicates the direction of the packet, TCP ports, segment length, and the flag(s) set. Wireshark automatically builds a graphical summary of the TCP flow.Įach row represents a single TCP packet. Navigate to Statistics > Flow Graph., select TCP flow and click OK. To better understand how sequence and acknowledgement numbers are used throughout the duration of a TCP session, we can utilize Wireshark's built-in flow graphing ability. However, be aware that the remainder of this article will reference relative sequence and acknowledgement numbers only. and un-checking Relative sequence numbers and window scaling under TCP protocol preferences. The display of relative sequence numbers can optionally be disabled by navigating to Edit > Preferences. This is handy, as it is much easier to keep track of relatively small, predictable numbers rather than the actual numbers sent on the wire.įor example, the initial relative sequence number shown in packet #1 is 0 (naturally), while the ASCII decode in the third pane shows that the actual sequence number is 0xf61c6cbe, or 4129057982 decimal. These numbers are relative to the initial sequence number of that stream. However, protocol analyzers like Wireshark will typically display relative sequence and acknowledgement numbers in place of the actual values. When a host initiates a TCP session, its initial sequence number is effectively random it may be any value between 0 and 4,294,967,295, inclusive. This sequence number is included on each transmitted packet, and acknowledged by the opposite host as an acknowledgement number to inform the sending host that the transmitted data was received successfully. The client on either side of a TCP session maintains a 32-bit sequence number it uses to keep track of how much data it has sent. These three packets complete the initial TCP three-way handshake. Packet #3, from the client, has only the ACK flag set. Notice that it has two flags set: ACK to acknowledge the receipt of the client's SYN packet, and SYN to indicate that the server also wishes to establish a TCP connection. Here we can see all of the TCP flags broken down. Select packet #1 in Wireshark and expand the TCP layer analysis in the middle pane, and further expand the "Flags" field within the TCP header. FIN - (Final) Cleanly terminates a connectionĪs we'll see, a packet can have multiple flags set.SYN - (Synchronize) Initiates a connection.The three we're most interested in here are: TCP utilizes a number of flags, or 1-bit boolean fields, in its header to control the state of a connection. Traffic from the client is shown in red, and traffic from the server in blue. You can right-click on any of the TCP packets within this capture and select Follow TCP Stream to open the raw contents of the TCP stream in a separate window for inspection.

The example capture contains a single HTTP request to a web server, in which the client web browser requests a single image file, and the server returns an HTTP/1.1 200 (OK) response which includes the file requested. This article aims to help you become more comfortable examining TCP sequence and acknowledgement numbers in the Wireshark packet analyzer.īefore we start, be sure to open the example capture in Wireshark and play along. Despite its age, TCP is a relatively complex protocol and well worth knowing intimately. If you're reading this, odds are that you're already familiar with TCP's infamous "three-way handshake," or "SYN, SYN/ACK, ACK." Unfortunately, that's where TCP education ends for many networkers.
