Understanding TCP Port Numbers Reused in Wireshark: Analysis and Examples

1. Introduction

By default, Wireshark’s TCP parser tracks the state of each TCP session and provides additional information when issues or potential problems, such as TCP Port numbers reused, are detected. Upon first opening a capture file, each TCP packet is analyzed in the order they appear in the packet list. This feature can be enabled or disabled through the “Analyze TCP sequence numbers” TCP parsing preferences.

2. TCP Analysis Display

When performing TCP analysis in a packet file, the message “TCP Port numbers reused” is typically displayed as follows: in the Info column of the Packet List window, marked in red on a black background as [TCP Port numbers reused]; in the Packet Details window, defined under the TCP protocol tree in [SEQ/ACK analysis] -> [TCP Analysis Flags].

3. TCP Port Numbers Reused

The definition of TCP Port numbers reused in TCP analysis is quite simple: it refers to a SYN packet (not SYN+ACK) where there is already an existing session using the same IP and port. If the sequence number of this SYN is different from the existing session’s ISN, it is marked accordingly. Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequence number is different than the existing conversation’s initial sequence number.

Note: The official documentation refers to SYN, rather than SYN/ACK, which differs from the actual code implementation. The following expands on this with specific code that primarily handles SYN and SYN/ACK packets, determining whether it is a new connection or a retransmission of an existing connection, thereby creating a new session or updating the session’s sequence number and relevant flags. Overall, this is an important part of how Wireshark analyzes TCP traffic, especially in identifying connections and updating status information.

/* If this is a SYN packet, then check if its seq-nr is different
 * from the base_seq of the retrieved conversation. If this is the
 * case, create a new conversation with the same addresses and ports
 * and set the TA_PORTS_REUSED flag. (XXX: There is a small chance
 * that this is an old duplicate SYN received after the connection
 * is ESTABLISHED on both sides, the other side will respond with
 * an appropriate ACK, and this SYN ought to be ignored rather than
 * create a new conversation.)
 * 
 * If the seq-nr is the same as the base_seq, it might be a simple
 * retransmission, reattempting a handshake that was reset (due
 * to a half-open connection) with the same sequence number, or
 * (unlikely) a new connection that happens to use the same sequence
 * number as the previous one.
 * 
 * If we have received a RST or FIN on the retrieved conversation,
 * create a new conversation in order to clear out the follow info,
 * sequence analysis, desegmentation, etc.
 * If not, it's probably a retransmission, and will be marked
 * as one later, but restore some flow values to reduce the
 * sequence analysis warnings if our capture file is missing a RST
 * or FIN segment that was present on the network.
 */

4. Packetdrill Example

First, a normal TCP three-way handshake can be simulated with Packetdrill, capturing packets through tcpdump to generate a tcp_port_number_reused.pcap file.

# cat tcp_port_number_reused.pkt 
0   socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0  bind(3, ..., ...) = 0
+0  listen(3, 1) = 0

+0  < S 0:0(0) win 10000 <mss 1460>
+0  > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 10000
+0 accept(3, ..., ...) = 4
#

Using editcap and mergecap, modifications are made to the pcap file, creating a merged tcp_port_number_reused.pcapng file.

editcap -t 0.1 tcp_port_number_reused.pcap tcp_port_number_reused_01.pcap
mergecap -w tcp_port_number_reused.pcapng tcp_port_number_reused.pcap tcp_port_number_reused_01.pcap

Wireshark displays the captured packets, highlighting that No.6 SYN has the same source/destination IP and ports as the previous TCP session, which had a FIN/RST, marking it as [TCP Port numbers reused].

5. Examples

Instances of TCP Port numbers reused are not very common, especially in scenarios where the client’s source port varies constantly. Even when observed, this phenomenon is not a significant issue; it simply indicates TCP port reuse and is flagged as a Note level warning with the message: [Expert Info (Note/Sequence): A new tcp session is started with the same ports as an earlier session in this trace]. Possible scenarios include a client connecting with a fixed source port but frequently receiving RSTs from the server, or under heavy capture conditions where the client initiates a new connection with the same source port after a long time.

5.1 Short-Term Repeated RST

This scenario involves rapid SYN RST events. TCP Stream 6 initiates a TCP three-way handshake but is RST rejected by the server. After a 500ms interval, the client attempts a new connection with the same TCP source port 52744, which again is RST rejected by the server. In this case, repeated SYNs will be marked as [TCP Port numbers reused], indicating that the same connection is being attempted repeatedly.

5.2 Long-Term Capture with Repeated SYN

This situation involves a lengthy capture where TCP Stream 24 completes the three-way handshake, data transfer, and the four-way handshake. After more than two hours, the client initiates a new connection with the same TCP source port 2266, which will mark the SYN in packet No.48015 as [TCP Port numbers reused], a normal occurrence without issues.

5.3 Repeated SYN/ACK

This section discusses repeated SYN/ACK scenarios and the setting of [TCP Port numbers reused]. Initially, a normal capture shows No.1-2 as one session and No.3-4 as another, where No.3 is marked as [TCP Port numbers reused]. If No.5 SYN is missing from the capture, No.6 SYN/ACK will also be marked as [TCP Port numbers reused], reflecting the logic described in the SYN/ACK code section.

5.4 Special Case of Repeated SYN/ACK

During experimentation, an unusual case of repeated SYN/ACK was found. Based on the following packet scenario, where No.4 SYN produces a [TCP Port numbers reused] marking. If No.4 SYN is not captured (simulated through ignore), both No.5 SYN/ACK and the previous No.2 SYN/ACK would also be marked as [TCP Port numbers reused]. This situation is perplexing, especially without RST conditions, but was confirmed as a bug by the official developers, awaiting resolution. Note: The tests were conducted on version 4.2.x, and the latest version 4.4.0 has already addressed this issue.

6. Conclusion

In summary, the analysis highlights the detailed handling of complex TCP scenarios within Wireshark, clearly distinguishing between new and existing connections.