TCP Tips and Tricks - SLOW APPLICATIONS? // Wireshark TCP/IP Analysis

[@hangeroo2439]

Some people really have a knack for distilling difficult topics and teaching them to people...you are one of these people. I love the way you explain things and how you go into visual details. It really helps those of us whom are a bit thick-headed to "get it" finally. THANK YOU!! Hope you keep doing these videos coming as there are so many videos out there, but yours are really thorough and you make extremely difficult subjects much more mentally attainable...it makes the learning much more enjoyable and less of a challenge.

[@ChrisGreer]

Thank you Hang for the feedback. I'll do my best to keep them coming!

[@judegary2766]

You prolly dont care at all but does any of you know a method to get back into an instagram account? I somehow forgot my login password. I appreciate any help you can give me

[@zionerick9414]

@Jude Gary Instablaster ;)

[@judegary2766]

@Zion Erick I really appreciate your reply. I got to the site thru google and im waiting for the hacking stuff now. Takes quite some time so I will get back to you later when my account password hopefully is recovered.

[@judegary2766]

@Zion Erick it did the trick and I finally got access to my account again. I am so happy:D Thank you so much, you saved my ass !

[@tonioyendis4464]

This is absolutely the best TCP analysis I've found on You-Tube! Thank you sir!!!

[@MrVecheater]

Normally I can't watch such long talks that teach stuff this one kept me hooked

[@ChrisGreer]

Thanks for the comment - glad you enjoyed it!

[@RowanHawkins]

Finally some one who gets it! I used to spend so much time at one place big on finger-pointing trying to get someone to run a trace. They always wanted to claim it wasn't their issue but no one wanted to prove it wasn't their issue because it might prove it actually was their issue. People who point fingers don't care about about finding solutions they care about avoiding blame.

[@DS-rw5zz]

This is classic. Really enjoyed it. Thanks for taking time and share it. Super loving it and am watching it over and over again tirelessly.

[@JDBoelter]

This helped me understand Wireshark and packet analysis (for TCP, anyway) better than anything else I've read or watched. Many thanks for providing this!

[@edzielinski]

Chris - this was a revelation to me and helped me analyze some very puzzling captures. Thanks for the excellent presentation and for making it available. Your presentation and explanations are extremely lucid, clear and vivid.

[@thechronic555]

Seriously i cant rave enough about how well you explain this! Thank you!

[@BrunoVernay]

Great stuff ! You are really a reference. One thing I noticed is that students confuse Wireshark's labels: "TCP Out-Of-Order" or "TCP Retransmission" as TCP properties! These labels are only Wireshark best guesses, not something written in the Packet itself.

[@ChrisGreer]

Thanks Bruno! I appreciate the comment.

[@DeepakSharma-li9cn]

This is best TCP packets analysis. Mind blowing video . It's really helpful for me.

[@ChrisGreer]

Glad it helped you!

[@emirh.9376]

Purchased a Wireshark course on Udemy but it is rather high level. These deep dive videos really compliment that course well. Bravo!

[@desert_rose7171]

Hi Emir. Was the wireshark course from udemy worth it and what’s the name of the course?

[@multechpro7151]

I love your videos, your explanations are as clear as cristal, hope you make more videos about troublshouting and how to read tracefiles and determine the problem source. Thanks Chris.

[@gillianlee8514]

excellent video on differentiating network packet drop and application performance. this is often a bone of contention between network and application teams. I took one of my traces from a customer site and used your tutorial to drill down what the issue is.

[@MultiRam73]

Technology stuff explained in pure conversational language, making us understand the concept underneath and retain for long. Thanks much for creating this wealth of information!

[@ChrisGreer]

Ram thank you!

[@sridiptah3186]

SIR YOU'RE GREAT!!! THANK YOU FOR TEACHING ME IN A PRACTICAL WAY WHERE & HOW TO LOOK OUT. LOVE FROM INDIA

[@ChrisGreer]

Thanks for being awesome and commenting!

[@sreenislg]

your Videos/other training material has inspired me to take for exam(WCNA) and I have passed it. I saw this video 3 times for now.. to become good with concepts. Thank you for all your efforts in preparing this video..

[@ChrisGreer]

Awesome! Congrats on passing the WCNA. That is a huge accomplishment and I am honored to have helped at least in a small way. Keep on learning and capturing.

[@chrisgast]

This really helped. Thanks for another perspective.

[@qatesta]

Chris, You are awesome. Your communication style is superb. thanks for the vids.

[@rohithreddy1693]

Nice explanation --and learn lot of basic troubleshooting on tcp concept

[@ChrisGreer]

Thanks for the comment Rohith!

[@maheshjadhav1606]

Excellent Explaination of the Transport layer stuff and how it works. It is very usefull to finding out the reason why the network is slow and aslo can provide suggetion to the Developer or the Network Engineer to rectify the issue.

[@ChrisGreer]

Thanks Mahesh! I appreciate the comment.

[@patgame]

Your courses should be on something where we could buy just a single course. Plural sight is a overkill :) Great video, the shortcuts especially were so helpful!

[@ChrisGreer]

Nice feedback Patgame - thank you. You could always just join Pluralsight for a month and watch them all for $29! But who knows, maybe i can get some other projects in the bag too. www.bit.ly/wiresharktcp

[@patgame]

@@ChrisGreer Thanks, Chris. You make a point on the monthly sub. Do you cover various congestion avoidance algorithms (read, reno/bic/cubic) and so on in your courses? I cannot seem to ascertain from the list of topics on PluSig

[@ChrisGreer]

@@patgame Yes! - I have a new course on Pluralsight that will come out in the next few weeks that covers the congestion control mechanism, and looks into CUBIC vs NewReno. It doesn't do a deep dive into each flavor, but it does cover how each one makes a decision of when to go into congestion avoidance and fast recovery. It is called Mastering TCP Analysis with Wireshark

[@patgame]

Chris Greer great stuff. Will definitely sign up then. See you there :)

[@metaworldtrendingvideos5262]

I am fan of this guy ❤

[@吕汉楠]

this turorial is very helpful, net work analyze is a very difficult and skillful job. very appreciate

[@ipadair8841]

Chris this is the best analysis on packet thanks for this

[@ChrisGreer]

Thank you! 🙏

[@surjeetyadav878]

it's great video to understand the packet and troubleshoot the live network issues. Thanks for teaching us :) :)

[@gofai2003]

you're doing great job chris

[@ChrisGreer]

Thanks for taking the time to give positive feedback. I really appreciate it!

[@sarwankumar5339]

Thanks Chris. It was really helpful. Had a great insight into TCP protocol functioning.

[@k3nbe]

This video just earned you a new subscriber 🎉

[@ChrisGreer]

Great! Welcome to the channel - Kick back, relax, and enjoy the content!

[@linhandcalvin7109]

You explain very well!

[@장병훈-d9w]

Really Great Lesson. Thank you very much

[@shaishankar8499]

Excellent video and i like to view your videos more!

[@harshakada3374]

Just Love ur videos. Amazing content TQSM

[@ChrisGreer]

Thanks Harsha! I will keep making them.

[@sreenislg]

This is awesome video... Thank you for taking time and presenting us

[@williamwilliam4907]

Thank you for this very insightful analysis of packet captures!

[@ChrisGreer]

Happy to help! Stay close to the channel for more content.

[@apolina79]

Chris, funny I am sysadmin and learning a lot from your training, really valuable to also understand when the problems are on our side. i am currently troubleshooting an issue of slowness and retransmission and one thing i noticed is TCP segment len 524 for entries showing that data sent PHS-ACK, is that so small that may be a factor? thanks a lot.

[@arunrattingal]

Hello Chris - I love to watch and take away from your great video sessions. Question: How we can confirm that, the IP Sec related ports are opened in a remote ISP if we have a host attached to that particular ISP.

[@talk2srj]

Chris.. I have no word to tell you how much amazing you are ! ;) super excellent tutorial :) Thank you very much :)

[@ChrisGreer]

Thanks for watching Suraj!

[@ksdeals]

Thank you but . My understanding at 25:00 is that Wireshark just captures the packets. If they are tcp packet is for dup or missing ....it all coming from client. Wireshark doesn't make requests to server. It simply captures. The size of your laptop you use for your Wireshark will not make dup or missing packets. Maybe I'm wrong but I'm almost sure about this .

[@augustbernard3396]

So excellent. Thank you!

[@upelister]

Thank you, very informative video.

[@gregtaane7434]

Outstanding explanation. This will help me no end . Thank you.

[@philipg8283]

Thank you. This was an excellent video!

[@ChrisGreer]

Thanks for watching Philip!

[@Test9383]

Excellent session.

[@samirshaikh52]

Awesome Video Chris! as always

[@RaviKumar-xc4bt]

thanks for the great explanation.

[@ChrisGreer]

Glad it was helpful!

[@HuzaifaGujjar]

Best TCP analysis.

[@ChrisGreer]

Thanks for the comment Huzaifa!

[@mailsidney]

thanks Chris. This was a very helpful video.

[@franciscosencion]

Great video, keep up the good work!

[@ohassairi]

wonderfull video . many thanks

[@ChrisGreer]

Thanks for commenting!

[@OthmanAlikhan]

Thanks for the video =)

[@AkashDeepSingh-lk7fv]

Thank you very much for this video.. Really needed this one..!

[@balaguru84]

clearly explained, thanks for the session

[@PaulOfford]

Great job Chris.

[@janetoss]

See 19:00-23:30 B 29:15

[@dominiquerossignol2212]

Hi Chris, could you supply a valid link to download the trace files ? Regards

[@vineet79]

Amazing info has been shared in this Video.

[@spyderkoh]

Awesome video!

[@subhamthemusicalguy8851]

Thanks Chris. I have a doubt about TCP OUT of order packets . what is that for?

[@ChrisGreer]

Out of orders mean that a packet arrived out of sequence. It can happen because a packet takes a different path than others behind it and it took longer to arrive, or more often, Wireshark can perceive retransmissions as arriving out of order. Great idea for a video!

[@feiwoza]

Thanks Chris !

[@NewHOD]

At the 1:00 how can we tell it was a single threaded TCP between Client - Server? Multi-thread would have shown the same Source & Destination IP pairs. Would the indicator be based on different ports used?

[@srikanthum4979]

Awesome! Thanks chris

[@MellexLabs]

Hi Chris. Trying to wrap my head around the TTL part of the video... I have two devices on the same subnet 10.106.63. And the trace is telling me that .48 which is the client has a TTL of 255 but when looking at an ACK of the packet the server part which is .11 its telling me a TTL of 128. Now one device is connected over wifi and the other over a cable... there is a VLAN setup with devices in between that I have no view of... my question is... isn't the client supposed to decrement the 255 value to at least 254 if there is one hop? There is only one set of ports open and I am monitoring on the server side. Thank for your help.

[@ChrisGreer]

Hello Malcolm - if the two devices are on the same subnet and packets do not need to be routed then the TTL will not be decremented between the two. Traffic in both directions will stay at 255 and 128 respectively. A Wifi access point and an ethernet switch are not routers, generally speaking, so they will not decrement the TTL. Hope this helps!

[@MellexLabs]

@@ChrisGreer Yes this helps tremendously. So with with network equipment not behaving as routers in the general sense, it also implies that windowing will not be modified between the 2 devices and that window size is purely between the endpoints?

[@priyavratarsenal]

great video!!! Priyavrat

[@bernafunda]

thanks for the good explanation . I have a question regarding to previous packet has not captured , in that case how I can tell the dropped the packet was sent from the sender or from the server side ? and the one just i received it later it is the retransmit one or the continuation ?

[@ChrisGreer]

Hello Nanis - Wireshark determines that a packet has been lost by looking at the gap in the sequence numbers. So if you see this warning, it means the previous packet in this direction was lost. So it depends on which direction the traffic is flowing. Also, consider where you are capturing. If you are capturing at the client end, most likely you will see this warning for packets that are coming from the server. Another possibility is that the packet was lost by the capture method (overprovisioned SPAN, exceeding the capture potential of the laptop or device doing the capture) so be careful when troubleshooting these warnings as they simply may indicate that the capture device simply missed a packet.

[@protek7028]

where i can get the pcap files used in this demo ?

[@sameerkumar2692]

Amazing 👌

[@caloye86]

Hi Chris, Just one question. If we increase the bandwidth of a dedicate link, the Windows Size initial negotiation could increase?

[@ChrisGreer]

Not necessarily. The window size is set by the operating system kernel, or by the application using that kernel. So it is independent of the network. Increasing the bandwidth may cause the TCP stack to dynamically increase the window size over time as more data moves, however that would be determined by the OS.

[@caloye86]

@@ChrisGreer I have an issue that after I change the network layer from IP MPLS network to a WDM OTN network using the same servers and with the same link capacity. The windows scaling increase drastically, having transfer rates from 4 MB/s up to 90 MB/s. This is why my question. The only difference is the iRTT time. With a 20ms difference between the two network layers. WDM OTN shows the best performance. I'm trying to find how to explain or justify this behavior. What else would you consider to check?

[@shion0]

is a : 0.000408000 seconds response time considered fast

[@VulcanOnWheels]

37:03 Please try to avoid pauses like this. For a moment I thought that my computer had frozen. I realize that this is an old video, but I would like to comment on how well I could read things. There were times when I could not read a line in the top pane because the colors of the background and the text clashed.

[@bigshawn10]

Chris I am starting a job soon and will be using wireshark for first time. Where is the best place to learn for beginners? Books, videos, etc...

[@ChrisGreer]

Hey Shawn - that's great! Welcome to the world of Wireshark. For sure check out the videos here on my channel for tips and tricks. For some more in-depth, personalized training, let me know if you are interested in a class. For books, check out Practical Packet Analysis by Chris Sanders. Awesome read. Hope this helps!

[@nitinsharma-xt2fy]

can't thank enough

[@jarbystark]

hey Chris, i have a strange packet behavior that repeats again and again. An app sends some data to my client , then retransmission of this packet goes for some reason and then my client ack. after this i get an unusual several seconds delay (between client ack and sending start) and client start sending data to server. This situation repeats again and again. What problem should i look for? You told about such situations on server side but what is it when delay is on client side ? By the way your courses on PluralS are great, enjoying every of it, thank you! )

[@ChrisGreer]

Hey! Can you share the pcap? If so… pop it over to me… [e-mail]

[@jarbystark]

@@ChrisGreer thank you very much ) sure ill send it

[@skr0nytbe389]

Hey Chris, thanks for the wonderful video.. I liked it. But, I wasn't quite happy with TCP window full conditions explained. I doubt u covered the zero window conditions.. Also on the window update capture, I could see a syn=1 and ack=1 in middle of the flow at a window update. How could this be possible???

[@ThePumbaadk]

This is great, thanks

[@iMPRE7ed]

Hey, i recently (lost the actual icident) had a complaint , and it really happened, on l2 segment one server was scp ing a file from other server. They were connected to same switch !!no hw issues. I saw about a half packets coming as normal, and then the receiver of file (initiated the conn) started getting dupe acks. What happens is transfer stalls at zero, but the receiver working properly, acked all seq in time , but sender's packets were missing,so rcvr sent ack for retrans. Btw, sacks and scaling were off..so i just saw delays from sender of file getting double time delay (every time double until 120 sec). What can that be guys, really curious, not a champ at wireshark yet :( crazy stuff

[@iMPRE7ed]

Only captured on source the receiver which is src, though. Might be just performance rlated on other end. Hard to tell, cuz im network guy, and they say server is green...

[@tommurphy2332]

In this video the details of creating a button for "Slow HTTP" has a mistake: if we enter "http.time > 1", it creates an error condition for an inappropriate argument and my Wireshark panel goes out of control. I had to go to the process manager and kill the Wireshark process. After doing that and restarting Wireshark, I needed to correct the button filter to read: "http.time > 1.0" because http.time is a floating point number and not an integer which the first filter spec was looking for. That's my two cents.

[@ChrisGreer]

Hmm interesting. Literally never seen that one. What version of WS are you running?

[@ajtheguy]

More often the Reps on the other end says 'The system is slow today' not necessarily blaming the network.

[@Sabliftsss]

excellent

[@sandroidbada112]

thank you

[@88ba14]

@chris please provide these captures please

[@ChrisGreer]

I don’t provide the pcaps on this one. Some of them are long gone…

[@88ba14]

Not clear about previous segment not captured

[@VivekSingh-rr3fr]

Wow :) Beautiful explanation.. I have a doubt regarding Window Full feature of Wireshark. In your capture, the segment from server in which we see "Window Full", that packet has 1460bytes of data. When the server knows that receiver's buffer is full, why is it sending more data? Or, does Window Full mean that receiver's buffer will be full after this segment?

[@VivekSingh-rr3fr]

You said that it's common to see Window Full and then some packet loss. Do you mean to see that server/host will burst traffic up to Window size and 'packets from this burst' may be dropped by network? Can you also confirm that it's not necessary that every time we see Window Full network will drop packets? Could you please explain more about this? Thank you very much :)

[@julianaputhota4249]

Yes - I have the exact same question. The explanation for Window-Full was a bit unclear in the lecture. He mentioned that Server has sent so much data to Client that the Window Size has become Full. Whose Window Size? Also, why is the Server sending more data when the Window Size limits are clearly mentioned in the TCP Conversation?

[@deepakjha81]

When a network capture is analyzed using Wireshark, 39% of the total traffic is RST packets. What could be the reason? The connection is trying to connect to a TCP port and the port is not open The connection is trying to connect to a UDP port and the port is not open The 3 way handshake is unsuccessful and there are multiple retransmissions and failures The TCP port at the source is a wrong port Please give me answer in above 4 option

[@sleekthegeek6669]

I worked at two call centers and I can tell you factually that they *do not* want you to admit that anything is wrong with their systems or computers it's the "other network/s" they're trying to connect to that is slow. They basically wanted us to say "Our network our servers our computers are fine It's the other end that is slow"

[@sleekthegeek6669]

And depending on your coach they'll have an excuse for everything credit cards taking too long? must be a lot of people buying right now. Man Mastercard servers are busy today.

[@ChrisGreer]

@@sleekthegeek6669 Wow really? I guess it doesn't surprise me. Thanks for the comment.

[@soniaketh5784]

nice one

[@looka84]

Impressive!

[@ChrisGreer]

Thanks Malak. I hope it helps!

[@shashireddy1879]

I have some issues running which is having a slowness while accessing the citrix application not able to figure out where the problem is, could you please help

[@ChrisGreer]

Sure - I'd be happy to. Please send me a contact request through www.packetpioneer.com/contact Thanks!

[@lyingrussians3258]

22:30

[@SantoshSharma]

Hi, Could you please suggest how to identify unicast storm. Not able to find any video

[@ChrisGreer]

DRSInfocom Online firewall training sure, that is a great idea for a video. I will be in my studio soon recording some new content!

[@SantoshSharma]

@@ChrisGreer thanks a lot Chris. The way you teach is awesome. That's the reason for request. 😊

[@hamzahabdulhadi5218]

where can I find the PCAP file for this tutorial ?

[@ChrisGreer]

Hello Hamzeh, here is a link to one of them - www.cloudshark.org/captures/b28b2cfec7ea I do share the trace file for several of my videos but I didn't do so for all the traces on this one. Thanks!

[@bevo260578]

supper helpful

[@sjurpejg]

Just saw your video, and compared to others out there yours really explained to me how to really use Wire Shark. Thank you.

[@knight2000-NC]

blaming the network has been a thing since the 90s. The vendor blame game is popular, too.

[@RussellTeapot]

8:48 I heard "..it will show us Tupacs" .... I was quite confused

[@ChrisGreer]

:-) Funny!

[@RussellTeapot]

@@ChrisGreer By the way, excellent video! I'm not an IT professional, only an enthusiast learning the ropes about how network communications work: so I don't troubleshoot often (my peak performance is turning off and back on the router), but seeing the different pieces "in action" with software like Wireshark helps to grasp the theoretical concepts. Aside from general tips about Wireshark (like conversation filters, buttons and others), I found that considering the layers stack from the perspective of the transport layer is very insightful and something I never thought about: either I focus on the lower part (physical, link, network) or the upper part (application, since session and presentation for me are still a mistery). I still have to digest the video, but it seems I have learned a valuable lession: since the transport layer is "in the middle", it points to the direction to follow when trying to understand what went bad. Thanks for the upload, I'm really glad I resisted the first "ugh! 1 hour of technical explanations on topics I barely understand? No thanks" impression , you are a great teacher!

[@jimmatrix7244]

System Administrations get bashed by management and users when the problem lies with developers and network administrator.

[@mauriciosiles2795]

You rock!!!

[@hassanalghamdi6047]

I'm here to proof that it is not network issue its application team issue 😁

[@tonyruiz2046]

⭐️👍⭐️

[@lifeislikedie9667]

I need the app can somebody help me

[@roihan9099]

u mean the wireshark software?

[@EricsVoiceOversUk]

They use the term in a less pedantic more general way, that's all.

[@frankm.6881]

Not going to the main topic. .

[@antikoerper256]

Great video!