Table of Contents
Introduction to TCP Retransmission
TCP is one of the reliable protocols working in the transport layer, in terms of Open System Interconnect (OSI) model. The protocol offers packet delivery guarantees, even if some of the packets have been lost during the transmission. The lost packets are recovered by retransmissions and acknowledgments while sequence numbers are used to determine correct packet reordering in the receiving side.
Whenever a sender transmits a packet, it saves a copy of the packet int its buffer and it stays there until receiving side acknowledges that it has received the packet. After that, the copy gets deleted and resources are released for future use.
Packet loss may happen due to two main reasons which can fall into many sub categories. Packet loss is mostly caused by hardware issues, software bugs, network congestion, and some other factors. Before diving into retransmissions and examining the types of retransmissions, we need to explain two concepts.
How to get TCP Round-Trip Time (RTT)?
For sake of simplicity, lets first go with pinging. I am using Windows OS and when I ping 188.8.131.52 address, it displays an output that shows me how much time it takes to send an ICMP packet from my computer to the server and gets back an answer from the server to my computer. The total time is called RTT for ping.
My ping command displays the RTT for each packet sent and returned below.
# ping 184.108.40.206Pinging 220.127.116.11 with 32 bytes of data:Reply from 18.104.22.168: bytes=32 time=12ms TTL=56Reply from 22.214.171.124: bytes=32 time=12ms TTL=56Reply from 126.96.36.199: bytes=32 time=11ms TTL=56Reply from 188.8.131.52: bytes=32 time=37ms TTL=56Ping statistics for 184.108.40.206: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 11ms, Maximum = 37ms, Average = 18ms
The similar concept can be applied to TCP as well. RTT is how long it takes to receive an ACK for data that has been sent. Wireshark is capable of calculating and displaying TCP RTT in the header. Let’s get our hands dirty and capture a TCP flow. We will measure RTT for the first packet (SYN) in the flow.
- Go to the TCP header and expand [SEQ/ACK Analysis] tree.
- You should see something like below.
As you see in the screenshot above, after SYN/ACK packet arrived, the RTT for the SYN packet has calculated as 0.229751 second.
Analysing TCP Retransmission Timeout (RTO)
When a packet is sent over a network, the sender starts a timer and expects the packet to be acknowledged before the timer expire. If the packet gets lost or the sender does not receive the acknowledgment in the time, the timer expires and the sender retransmits the packet again. This timer is called RTO which is doubled after each retransmission. When RTO is calculated, RTT parameter is taken into account. The number of retransmissions depends on what type of operating system (OS) you use or what kind of configuration they have. I will create 3 scenarios in which we will observe RTOs and retransmissions.
In this scenario, we will use a Windows 10 client and try to reach 220.127.116.11 (dns.google) through port 125, which we know it is filtered by a firewall. All our packets will be dropped. The screenshot is below.
As you see, 4 times retransmission happened before it gave up. Each time RTO doubled in the “Delta” column. RTO timer can be customized in Windows 10.
We will repeat the same test with Kali. It has turned out that Kali is more stubborn compared to Windows 10 in terms of retransmissions. It tried 13 times before it gave up. You can see how RTO increased in the figure below.
In this scenario, we will create the topology below in which two Cisco routers are connected to each other. The client will try to telnet to the server but it will fail due to our configuration.
We will configure the server so that it will drop all the telnet traffic coming from the client. I prepared a configuration that did the filtering. The configuration is below from my Cisco router.
!ip access-list extended TELNET_TRAFFIC permit tcp any host 192.168.1.1 eq telnet!class-map match-all SELECT_TELNET match access-group name TELNET_TRAFFIC!policy-map DROP_TELNET_TRAFFIC class SELECT_TELNET police cir 8000 conform-action drop exceed-action drop violate-action droppolicy-map test!interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 speed auto duplex auto service-policy input DROP_TELNET_TRAFFIC!
Now, it is time to telnetting to the server from the client while we are capturing the packets between two parties.
client# telnet 192.168.1.1Trying 192.168.1.1 ...% Connection timed out; remote host not responding
It appears that our filtering is working and we will verify that with packet capture as well. The pcaps are below.
The Cisco router does not seem to try much. It retransmitted only once and then gave it up. All 3 scenarios have proved that different OS uses different implementation for retransmission. This information can be used in OS fingerprinting.
Analysing TCP Retransmission
TCP Retransmission happens when RTO timer expires. For better understanding, we will continue with more scenarios.
In this scenario, we will imitate packet loss with filtering only http responses coming from a site and examine the captures. Filtering will be made in a node between the client and the server. The captures are below.
Since only http packets coming from the server has been dropped, TCP 3-way handshaking is looking successful. Then the client creates a http GET request and RTO timer starts for that packet (in the row 4).
The packet arrives the server and the server responses back. When the packet reaches our filtering node between the client and the server, the node immediately drops the packet. The client is still waiting for the packet. A soon as the RTO expires, the client retransmits the packet number 5 but still gets no response from the server. It keeps retransmitting the packet until it gives up in the packet number 22 by which it resets the connection.
The RTO increase can be seen in the “Time” column.
We will imitate a low bandwidth, creating an artificial congestion then we will try to download a nice wallpaper and observer what happens in the packet level. I will create a Quality of Service (QoS) rule on node between the client and server, which limits the bandwidth at rate of 8kbps (kilo bit per second). The size of wallpaper is 888KB (Kilo Byte).
Since TCP 3-way handshaking consumes very low bandwidth, the artificial congestion does not seem to affect the first 7 packets. After that you can see the latency in the packet number 8. The latency increases dramatically. Although there are pretty much latency, we do not see any RTO in the first 23 packets. The reason is high RTT. Remember that RTT is taken into consideration when calculating RTO. Then RTOs and retransmissions happen so much that the connection gets terminated later without completing the download.
When I opened the wallpaper, I saw the picture below:
It reminded me the time when we used dial up connection for the internet 😊
What is Fast Retransmission
When a TCP sender receives three duplicate acknowledgements with the same acknowledge number, the sender concludes that the packet has been sent is lost and it retransmits the packet without waiting the RTO for the packet. This method is used to avoid congestion and detect lost packet in the network faster than normal TCP retransmit.
How to filter TCP Retransmissions with Wireshark
Wireshark provides a useful feature called “Expert Info”. When Wireshark see some anomalies, it adds some description to packet header, especially for TCP. It analyses TCP flags and inserts a relevant description to the header for informing experts (administrators). We can create a filter and make a “display filter button” for it. Steps are below.
Go to display filter and type
analysis.flags && !tcp.analysis.window_update. My output before filtering is below.
Now I am applying the filter below.
After applying the display filter, go to top right and click on the “plus” button.
Fill all the relevant areas and click “OK” to save.
Now you have a button that points to your filter. You should see something like below.
TCP retransmissions happen when there is packet loss or congestion, which causes high latency and low speed. TCP implements many methods to recover connections when packet loss occurs. Retransmission and Fast Retransmission are both used for this purpose.
What is a TCP retransmission in Wireshark? ›
TCP Retransmission - Occurs when the sender retransmits a packet after the expiration of the acknowledgement. TCP Fast Retransmission - Occurs when the sender retransmits a packet before the expiration of the acknowledgement timer.How to detect TCP retransmission? ›
Then, in order to detect if a re-transmission has happened, you simply know it if the same source has sent a TCP segment with a sequence number that's lower than the expected seq_num + 4 + 1 . Say, instead of getting seq_num + 4 + 1 in the next transmitted TCP message, you got seq_num .How to analyze TCP packets using Wireshark? ›
- Step 1: Start Wireshark. ...
- Step 2: Select an interface to use for capturing packets. ...
- Step 3: Start a network capture. ...
- Step 1: Open a browser and access a website. ...
- Step 2: Stop the capture. ...
- Step 3: Analyze the captured output. ...
- Step 4: Filter the capture to view only TCP packets.
A retransmission should be flagged as "TCP Retransmission" in the info column in Wireshark. It has the same SEQ and ACK values as the lost packet, but a different IP ID (ip.id) in the IP header. Duplicate packets should be flagged as "TCP Spurious Retransmission" or "TCP Out-of-Order" in the info column.What triggers TCP retransmission? ›
Common reasons for retransmissions include network congestion where packets are dropped (either a TCP segment is lost on its way to the destination, or the associated ACK is lost on the way back to the sender), tight router QoS rules that give preferential treatment to certain protocols, and TCP segments that arrive ...How many TCP retransmissions are normal? ›
The retransmission rate of traffic from and to the Internet should not exceed 2%. If the rate is higher, the user experience of your service may be affected.
TCP retransmissions happen when there is packet loss or congestion, which causes high latency and low speed. TCP implements many methods to recover connections when packet loss occurs. Retransmission and Fast Retransmission are both used for this purpose.Does TCP retransmission mean packet loss? ›
The TCP retransmission means resending the packets over the network that have been either lost or damaged.How does Wireshark detect TCP packet loss? ›
Click “Statistics” in the menu bar. Select “Capture File Properties.” A new window will open. Under “Interfaces,” you'll see “Dropped packets.” The number underneath it will tell you how many packets weren't captured.How does Wireshark detect RTP packets? ›
- On the Wireshark packet list, right mouse click on one of UDP packet.
- Select Decode As menu.
- On the Decode As window, select Transport menu on the top.
- Select Both on the middle of UDP port(s) as section.
- On the right protocol list, select RTP in order to the selected session to be decoded as RTP.
What causes TCP spurious retransmission? ›
In TCP, a spurious packet retransmission can be caused by either spurious timeout (STO) or spurious fast retransmit (SFR). The “lost” packets are unnecessarily retransmitted and the evoked congestion control process causes network underutilization.What is a TCP duplicate ACK in Wireshark? ›
Wireshark differentiates several categories of TCP retransmission; see the Wireshark TCP Analysis documentation for more information. TCP Duplicate ACK: When a TCP receiver receives packets out of order, which it interprets as data loss, it sends an ACK indicating the expected sequence number.How to simulate TCP retransmission? ›
You could try setting firewall rules that block the packets going from the server to the client, which would cause the client to re-transmit the quests. On Linux, this would probably be done using iptables, but different distributions have different methods of controlling it.How can TCP receive lost packet again? ›
Transmission Control Protocol.
If a packet is lost, TCP can retransmit it. The second transmission picks up lost packets and reconstructs the data stream. However, this does not mean there is no slowdown involved. The network may feel slower, as it still takes time to retransmit data.
The retransmission timer is initialized to three seconds when a TCP connection is established. However, it is adjusted on the fly to match the characteristics of the connection by using Smoothed Round Trip Time (SRTT) calculations as described in RFC793.How many TCP connections is too many? ›
On the TCP level the tuple (source ip, source port, destination ip, destination port) must be unique for each simultaneous connection. That means a single client cannot open more than 65535 simultaneous connections to a single server. But a server can (theoretically) serve 65535 simultaneous connections per client.What happens if TCP packets arrive out of order? ›
If too many packets are received out of order, TCP will cause a retransmission of packets similar to what happens with dropped packets. As such, the impact of out of order packets on goodput is similar to the impact of packet loss.Why are layer 2 retransmissions bad for our networks? ›
Layer 2 retransmissions increase overhead on the access point and therefore decrease throughput, leading to calls to the helpdesk. Users of VoIP over the wireless will experience latency and jitter due to them being time sensitive applications.How is TCP connection loss detected? ›
In TCP there is only one way to detect an orderly disconnect, and that is by getting zero as a return value from read()/recv()/recvXXX() when reading. There is also only one reliable way to detect a broken connection: by writing to it.Why can Wireshark see all network traffic? ›
By default, Wireshark only captures packets going to and from the computer where it runs. By checking the box to run Wireshark in promiscuous mode in the capture settings, you can capture most of the traffic on the LAN.
What effect do TCP retransmissions have on throughput? ›
If retransmissions are frequent, then the throughput often goes back to a minimum level and never reaches an optimal level. This means a much larger Data Transfer Time value, because the throughput to transfer the application response remains very low. This phenomenon is what is usually called a TCP Slow-Start.How do you test for packet loss? ›
The best way to measure packet loss using ping is to send a large number of pings to the destination and look for failed responses. For instance, if you ping something 50 times and get only 49 responses, you can estimate packet loss at roughly 2% at the moment. Anything over 5% is of concern.How does TCP detect if a packet is corrupted? ›
- Checksums: TCP uses a checksum to detect errors in the data that is being transmitted. ...
- Sequence and Acknowledgment Numbers: TCP uses sequence and acknowledgment numbers to keep track of the packets being sent and received.
There are four common reasons for packet retransmission: (1) the lack of an acknowledgement that data has been received within a reasonable time, (2) the sender discovering that transmission was unsuccessful (usually through out of band means), (3) the receiver notifying the sender that expected data hasn't been ...What does ACK mean in Wireshark? ›
ACK means that the machine sending the packet with ACK is acknowledging data that it had received from the other machine. In TCP, once the connection is established, all packets sent by either side will contain an ACK, even if it's just re-acknowledging data that it's already acknowledged.How do you perform a protocol analysis? ›
The first step of a protocol analysis is to obtain, and then transcribe, a verbal protocol. The next step is to take the protocol and use it to infer the subject's problem space (i.e., infer the rules being used, as well as various knowledge states concerning the problem).What is the best way to learn Wireshark? ›
- Wireshark: Packet Analysis and Ethical Hacking: Core Skills [UDEMY] ...
- Wireshark for Basic Network Security Analysis [Coursera] ...
- Start Using Wireshark to Hack like a Pro [Udemy] ...
- Wireshark Essential Training Online Class [LinkedIn Learning]
Wireshark is much easier to learn when you take this course and try everything you see for yourself! Wireshark is a free open-source packet analyzer that is the number one tool for network analysis, troubleshooting, software and communications protocol development, and related education in networking.How do I Analyse a Wireshark PCAP file? ›
PCAP analysis. To load a PCAP file in Wireshark, open Wireshark and in the menu bar, click 'File', then click 'Open' and navigate to the file's location, then click 'Open. ' In our analysis of the PCAP file, we will try three analysis techniques to find any indicators of malicious activity.Does Wireshark capture before or after firewall? ›
Wireshark operates "before" firewall and sees all the packets that the network card receives. Then the packets get filtered by the firewall running on the PC.
Does Wireshark capture frames or packets? ›
Wireshark can capture only the packets that the packet capture library - libpcap on UNIX-flavored OSes, and the Npcap port to Windows of libpcap on Windows - can capture, and libpcap/Npcap can capture only the packets that the OS's raw packet capture mechanism (or the Npcap driver, and the underlying OS networking code ...How do I monitor port traffic with Wireshark? ›
Click for more information:
- BACnet Explorer.
- BACnet Router.
- Software Tools.
Observe the packet details in the middle Wireshark packet details pane. Expand Secure Sockets Layer, TLS, Handshake Protocol, TLS Session Ticket, and Encrypted Handshake Message to view SSL/TLS details. Observe the encrypted handshake message. This is the server confirming the encrypted session.How does Wireshark check DNS traffic? ›
To analyze DNS query traffic: Observe the traffic captured in the top Wireshark packet list pane. To view only DNS traffic, type udp. port == 53 (lower case) in the Filter box and press Enter.What does TCP spurious retransmission mean in Wireshark? ›
Spurious Retransmissions are one's that are considered unnecessary -- in Wireshark, a retransmission is marked as "spurious" when Wireshark has seen the ACK for the data already.Why is TCP fast retransmission? ›
TCP fast retransmit processing improves TCP/IP performance by detecting lost messages in the network faster than normal TCP retransmit processing. The z/TPF system keeps a copy of packets that are sent to remote nodes until the remote nodes return an acknowledgement (ACK) to indicate that they received those packets.What is a RST packet in Wireshark? ›
A reset packet is simply one with no payload and with the RST bit set in the TCP header flags. There are a few circumstances in which a TCP packet might not be expected; the two most common are: The packet is an initial SYN packet trying to establish a connection to a server port on which no process is listening.What is TCP retransmission after ACK? ›
A TCP segment sent by the sender may get lost on the way before reaching the receiver. This causes the receiver to send the acknowledgement with same ACK number to the sender. As a result, sender retransmits the same segment to the receiver. This is called as TCP retransmission.Would TCP retransmit if it receives the same ACK twice? ›
TCP now uses duplicate acks as well as timeout to retransmit a packet if lost. Duplicate acks are used as a part of fast retransmission and packet recovery. Generally, if tcp timer expires , it is assumed that the packet is lost and tcp retransmits the same packet. But it need to wait, until the timer expires.What is seq and ACK in Wireshark? ›
According to the corresponding wiki page: By default Wireshark and TShark will keep track of all TCP sessions and convert all Sequence Numbers (SEQ numbers) and Acknowledge Numbers (ACK Numbers) into relative numbers.
What does TCP retransmission mean? ›
What Is TCP Retransmission? TCP (the Transmission Control Protocol) connects network devices to the internet. When an outbound segment is handed down to an IP and there's no acknowledgment for the data before TCP's automatic timer expires, the segment is retransmitted.What is the difference between TCP fast retransmission and TCP retransmission? ›
TCP fast retransmit processing improves TCP/IP performance by detecting lost messages in the network faster than normal TCP retransmit processing. The z/TPF system keeps a copy of packets that are sent to remote nodes until the remote nodes return an acknowledgement (ACK) to indicate that they received those packets.How to use Wireshark to capture packet loss? ›
Click “Statistics” in the menu bar. Select “Capture File Properties.” A new window will open. Under “Interfaces,” you'll see “Dropped packets.” The number underneath it will tell you how many packets weren't captured.How do I check for TCP packet loss? ›
- Open Command Prompt/Windows PowerShell (either will work) Right click the windows icon in the bottom-left corner. ...
- Enter the command as follows: ping -n 100 18.104.22.168. ping = The command to ping, leave unchanged. ...
- Check the summary when completed for percentage of packet loss.
TCP connections can detect lost packets using a timeout.What causes TCP out of order and retransmission? ›
What Causes Out-of-Order Packets? Multiple Paths: Out-of-order packets can be caused by data streams following multiple paths through a network (such as traffic traveling through the Internet), or via parallel processing paths within network equipment that are not designed to ensure that packet ordering is preserved.How many times unacknowledged data is retransmitted? ›
MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default)What is spurious retransmission in Wireshark? ›
Spurious Retransmissions Defined
Spurious Retransmissions are one's that are considered unnecessary -- in Wireshark, a retransmission is marked as "spurious" when Wireshark has seen the ACK for the data already.
Move to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. From the Edit menu select New - DWORD value. Enter a name of InitialRtt and press Enter. Double click the new value and set to the number of milliseconds for the timeout, e.g. 5000 for 5 seconds (the old default was 3 seconds).