Ask Your Question

very low TCP RTOs

asked 2020-03-23 17:54:17 +0000

Axel.F gravatar image

updated 2020-03-23 18:02:21 +0000

Hi there, i'm new to the wireshark community and looking for some help.

Since a few weeks, users in my company are complaining about slow SSH connections to linux servers. They work from a distant network ( MPLS or VPN). The whole infrastructure (servers & switching) is in a datacenter, carried by some Nexus 5000 and Nexus 2000 with multiples Vlans. The routing is managed by an old fortigate F1240B, which has not been updated since v5.0

After capturing some traffic, I see that I get a huge amount of TCP retransmission, and not only for SSH connections. Looking deep into the tcp frames, I see that the initial RTO is between 1 and 5 µS which looks very low.

Are such RTO normal ? If no, what can cause this and how can I solve this problem ?

Any help would be appreciated. I searched hours on the web but could find any answers..

As I understand, RTOs are defined by TCP and not applications or OS ?

edit retag flag offensive close merge delete


If you can anonymize a capture with something like TraceWrangler or one of the tools here, post it to a public file sharing site like Google, Onedrive, S3,... then update your question with a link to the file.

Chuckc gravatar imageChuckc ( 2020-03-23 18:48:21 +0000 )edit

Please find the capture here :

Axel.F gravatar imageAxel.F ( 2020-03-24 08:18:38 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2020-03-24 10:07:51 +0000

SYN-bit gravatar image

I took a look at a few retransmissions in your capture. They are not retransmissions, but they are duplicate packets. Duplicate packets mess up the TCP analysis engine of Wireshark.

You can tell that they are duplicates instead of retransmissions by looking at the field of the packets. A true retransmission is a new IP packet, so it would have a new The retransmissions have the same as the original packet, that means somehow they are either duplicated on the network or duplicated during the capturing process.

As the ip.ttl and the mac addresses of the first packet is different from the first "retransmission" you seem to be capturing before and after a routing hop, which also messes with Wireshark's TCP analysis engine.

So, please make sure you capture all packets only once.

edit flag offensive delete link more


I did the capture directly from the firewall, and converted it to pcap file. This is maybe the reason of duplicates, as the FW is also the router.

In other words, it means my problem has nothing to do with low RTOs :/

BTW, how is it possible that on duplicate packets the RTO is different ?

Thanks for your analysis !

Axel.F gravatar imageAxel.F ( 2020-03-24 12:34:14 +0000 )edit

(I converted your "answer" to a "comment" to keep the logic of this site intact)

What do you mean with the RTO on duplicate packets? RTO stands for "Retransmission Timeout" and it is the timer that is used to trigger a retransmission when no ACK has been received. As there are no retransmissions in your trace, what do you mean by RTO?

Or do you use the term RTO for the round trip time (RTT) between data and it's acknowledgement? In which case the answer is that the RTT calculation done by Wireshark is also messed up by duplicate packets.

SYN-bit gravatar imageSYN-bit ( 2020-03-24 12:40:51 +0000 )edit

Yeah, I'm talking about retransmission timeouts. I understand that there are no retransmissions in my capture but duplicates as you explained. So, if I understand, 2 captures of the same packet (aka duplicate packet) will show the same info, but the RTO is different. (ie packet 15 & 16 in the capture) I don't get this

Axel.F gravatar imageAxel.F ( 2020-03-24 13:11:23 +0000 )edit

Now I see what you mean, Wireshark calculates an RTO for you (had not seen that before, wondering if that is new in 3.2). Since Wireshark does not recognize the duplicates, it thinks these are retransmissions of frame 14 and calculate the RTO based on that. But since they are not retransmissions, the calculated RTO also do not make sense and should not be looked at :-)

SYN-bit gravatar imageSYN-bit ( 2020-03-24 13:52:45 +0000 )edit

Thanks for you explanations, its clear for me now ;)

Axel.F gravatar imageAxel.F ( 2020-03-26 09:25:01 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-03-23 17:54:17 +0000

Seen: 643 times

Last updated: Mar 24 '20