How TCP RETRANSMISSIONS Work // Analyzing Packet Loss
HTML-код
- Опубликовано: 1 июл 2024
- In this video we are going to dive into retransmission analysis. When we see them, what caused them? What can we do about them? In this hands-on video, make sure to download the pcap below so you can follow along as we study a problem that was due to a low network MTU on the path.
---------Download the pcap here----------
packetpioneer.com/wp-content/...
== More On-Demand Training from Chris ==
▶Getting Started with Wireshark - bit.ly/udemywireshark
▶Getting Started with Nmap - bit.ly/udemynmap
== Live Wireshark Training ==
▶TCP/IP Deep Dive Analysis with Wireshark - bit.ly/virtualwireshark
== Private Wireshark Training ==
Let's get in touch - packetpioneer.com/product/pri...
Hope this helps Packet People! Please like, share, subscribe!
Chapters:
0:00 Intro
1:01 Configuring Wireshark
1:54 Retransmission Analysis
3:05 The Retransmission Timeout
6:12 Digging Deeper into the Cause
8:39 Other Types of Retransmissions 
Наука
I’m a senior TAC engineer at Cisco and currently mentoring new hires in my team , I have shared your channel for them to brush up their wireshark skills and I must say that my students are super impressed with you Chris, Great Job!! these videos are gold .
Thank you! By chance are you at Cisco live? Let’s meet up!
Cisco TAC Engineer here as well and damn this guy is really good!
Thank you Chris, your way of explaining very complexe things in a simple and direct way is very valuable.
As a CIS student, I'm glad I happened on your channel. I've been messing with my home router using SQM and observing packets. TCPs went from Out of order running a speed test to TCP Dup Acks after SQM scripts are loaded. Learning to put this stuff in context has been really helpful.
Been learning so much from your videos. Thanks you Chris
Thank you very much for all the knowledge you have been sharing!!!
What a valuable video! I have learned too much from you Chris, thanks a lot!
Glad it was helpful! Thanks Raul.
Learning layer 4 (transport-layer) is crucial to troubleshooting network/application issues! Most app and most server teams don't understand the importance of TCP- tuning; they have little clue about window-scaling/sizing, SACK-tuning or how much retrans is too much. The BDP calculator is your friend as a network-analyst, most of the issues I discover are usually at layer 4 or below.
Very interesting video, you’re now in my go to channels list.
Thanks for the comment!
These videos are so good I can't believe they aren't more widely recognised
Thank you!
One of the best video on explaining the reason for retransmission.. Subscribed your channel.. looking for more videos..on packet analysis
Nice post, looking for depth on this topic Chris. Thanks
Great Praveen! Great you have to stop by the channel.
What else is there to say, informative and well presented. Like your videos a lot
I appreciate that - Thank you for stopping by the channel!
thnk you chris,i am a technical support negineer for several years,feel i am gaining good enough knowledge here
Thanks for the comment!
Great video and explanation, thanks
Always the best.
Great content. Thank you for much for it.
Glad it helps!
Thanks for making it.
Always facing Retransmission issues, This video is a life save. :)
Glad it helped! Thanks for the comment.
way better than the provided lecture notes at university -> best way to learn for the practical exam is to watch your videos! 👍
Glad you think so!
Great video! Thank you!
Glad you liked it!
Thank you Chris. This really helped me 😁
You're very welcome!
Thank you for the informative video.
Thanks for the comment Girish!
Need more videos on RETRANSMISSION
Hello Chris, once again...Thanks ;-)
Happy you stopped by and thank you for the comment.
Great Chris
Amazing Content ! Please continue to upload such videos regularly.
Suggestion for next video: I would like to see PCAP analysis of a voip call with choppy audio/One Way audio.
Nice suggestion, thanks!
Great Idea. Kinda similar problem. I have a partially (what ever that means) working VoIP-phone behind a second router (USG3 Ubiquiti). The phone works well at the first router (AVM Fritzbox 7940 - a consumer router very popular in the EU in particular in Germany ) which runs the software and my other phones.
Even if this is not going to be covered, it would be very interesting to see some VoIP "debugging" in general.
amazing video , thanks so much
Glad you liked it!
Would love to see a video on SIP packet troubleshooting :)
Thanks for the idea!
I always wait for uer new video 👍
More to come!
Thank you!
Very good information
Thanks
Great tips Thanks a lot
My pleasure!
Thanks Chris!
You bet!
Thank you so much!
You're welcome!
Hello Chris,
Great videos, on a particular case where we have a constant but high latency, is it a good idea to have frto or is a better approach to deactivate the frto at the source.
Thanks.
Thanks!
Thank you!
Hey Chris, great video. Just a quick confirmation, in the three way handshake, I see the (TX - Sender) has a MSS of 1460 whereas the (RXR - Server) has a MSS of 1440. Could that be a potential problem, or based on the three handshake. Will both parties agree to some diligence in the network like with windowing sizing? Thanks
Great question - The easy answer is no. The MSS is not negotiated, so both ends are allowed to support different values. The MSS is an advertisement of the largest segment that the endpoint can receive. In effect, telling the other side not to send anything larger than this length of payload in one segment. After that, TCP leaves it to IP to sort out MTU and fragmentation.
Hi, in an holistic troubleshooting method I would like to get some quick view informations table about the many tcp connections I can capture in my trace files.
For each TCP connections I would like to find , the number of packet retransmitions, ther average TCP RTT, the average application RTT, the number of 0 window, and so on.
Is there any way to get this in Wireshark ? Or is there any other packet analyser doing this on the market ?
Hi Chris, Great Stuff as always! I've a question. Why is server/receiver trying to send with the default MSS value of 536 when it has already negotiated its MSS value of 1440 during TCP 3-way handshake (SYN-ACK)?
That is the "When in doubt" default MSS. So if one side or the other is uncertain of the MSS due to retransmission, or a network-level change of MSS, it will try 536 as a last ditch effort before quitting.
U are awesome 🤠
Thanks for watching!
Chris, how do we analyze or troubleshoot esp/ipsec packet loss in wireshark?
Easiest answer? It's complicated. 😄 I rarely get in and try to decrypt it. Mostly I watch for shifts in roundtrip time, throughput, and network indicators of loss (ICMP or other layer 2 protocols). Or... I forget trying to capture the tunnel itself and install Wireshark on one of the endpoints and capture before traffic enters the tunnel. If things look healthy going in and coming out, then I move to the encrypted traffic.
@@ChrisGreer thanks a lot
boom ...more knowledge transmitted successfully from server(Chris) to client(me).
I'm here because David bom and subscribed 🎉🎉🎉🎉🎉🚀🚀🚀🚀🚀🚀
Welcome to the channel!
Video 3
What causes [TCP Retransmission] [TCP Port numbers reused] and how to fix it?
Awesome video and series. Simple and stupid question, what's a MTU ?
ruclips.net/video/XMcYwr-yJGA/видео.html - Here ya go. Here is a video about it.
Thanks Chris, the video was perfect. Funny thing, it was the next video in the series I was watching on your playlist. The TCP series is well done. I would like to see a deep dive into UDP.
Hey can you please explain me that what is "client hello" which is written in 4th line after 3 way handshake.
Hello, it's the first request from the client to the server telling him : " Hey, I want to make a secure (TLSv1.2) communication with you.
But unfortunately the server doesn't answer in the Chris example.
Take a look at this Wikipedia TLS page : en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
What WiresharkMania said.... Basically it is the first part of the TLS handshake. Now I need to do a series on that, so thanks for the question!
All TAC and Escalation engineers watching this video, give a like !
Always the same problem - having 2 thumbs but only 1 thumb up allowed to give!
So please feel it doubled
Thanks for the comment!
Hi Chris, I know you are not troubleshooting just for anyone so I would like your input to guide me to resources to help me find out what is wrong with my connections. I don't know what to ask I dont know what to look for so a bit of guidance to the right direction would be a great help.
My clients can't seem to connect to a certain website, im sure my firewall does not allow this connection. But my firewall log says it allowing it. I decided to check packet logs and found that my TCP SYN "conversation completeness: incomplete 37". I'm guessing my firewall will not trust that. Of course, without firewall, I tried to access the website which works but I also see my TCP SYN "Conversation completeness: incomplete, DATA (15)".
on firewall: TCP sequence is Client SYN (time:1) > TCP Retransmission x 4 > Server ACK (time 16) > Client TCP RST (time 16)
Where should I go? What could be causing this?
If your conv completeness is that high, sounds like you are getting a reset. Guessing it’s a syn/rst. Look at the TTL of the reset and see if it is coming from a local or nearby device. Check out my video on tshooting resets I walk you though all that.
@@ChrisGreer Thank you Chris! will do
If the smallest MSS allowed by TCP is 536. Why is packet 16 314
I get why that is confusing! So 536 is the minimum value that the MSS can be. So it is a minimum maximum. Packets can still be smaller than that, but the max needs to be at least 536.
!!!