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 .
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.
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.
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.
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.
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 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.
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.
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.
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 ?
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.
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.
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
![[ TEASER ] เงาะป่า - วงL.กฮ. | TMG RECORD](http://i.ytimg.com/vi/M4ObdFfcPww/mqdefault.jpg)
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!
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!
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.
Always facing Retransmission issues, This video is a life save. :)
Glad it helped! Thanks for the comment.
These videos are so good I can't believe they aren't more widely recognised
Thank you!
Thank you Chris, your way of explaining very complexe things in a simple and direct way is very valuable.
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.
thnk you chris,i am a technical support negineer for several years,feel i am gaining good enough knowledge here
Thanks for the comment!
Very interesting video, you’re now in my go to channels list.
Thanks for the comment!
One of the best video on explaining the reason for retransmission.. Subscribed your channel.. looking for more videos..on packet analysis
What a valuable video! I have learned too much from you Chris, thanks a lot!
Glad it was helpful! Thanks Raul.
Would love to see a video on SIP packet troubleshooting :)
Thanks for the idea!
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!
Been learning so much from your videos. Thanks you Chris
Nice post, looking for depth on this topic Chris. Thanks
Great Praveen! Great you have to stop by the channel.
Thank you very much for all the knowledge you have been sharing!!!
Hello Chris, once again...Thanks ;-)
Happy you stopped by and thank you for the comment.
Great video and explanation, thanks
Need more videos on RETRANSMISSION
Thank you for the informative video.
Thanks for the comment Girish!
I always wait for uer new video 👍
More to come!
Always the best.
Great content. Thank you for much for it.
Glad it helps!
Great video! Thank you!
Glad you liked it!
Thank you Chris. This really helped me 😁
You're very welcome!
Thanks for making it.
Thank you so much!
You're welcome!
What causes [TCP Retransmission] [TCP Port numbers reused] and how to fix it?
amazing video , thanks so much
Glad you liked it!
I'm here because David bom and subscribed 🎉🎉🎉🎉🎉🚀🚀🚀🚀🚀🚀
Welcome to the channel!
Great tips Thanks a lot
My pleasure!
boom ...more knowledge transmitted successfully from server(Chris) to client(me).
Thanks Chris!
You bet!
Great Chris
Thank you!
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.
All TAC and Escalation engineers watching this video, give a like !
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.
Awesome video and series. Simple and stupid question, what's a MTU ?
th-cam.com/video/XMcYwr-yJGA/w-d-xo.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.
U are awesome 🤠
Thanks for watching!
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.
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.
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 ?
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
Video 3
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
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!
!!!
Very good information
Thanks