Troubleshooting with Wireshark - Find Delays in TCP Conversations

[@vikaspotadar]

Chris deserves more subscribers. Contents are great and explained well.

[@hennessy6996]

This was a nice subtle vid to remind people on timestamp importance. Thanks, very much appreciated.

[@ChrisGreer]

Thanks for the comment!

[@peterchuk1923]

Well explained, important information for super users questioning ICT about networking traffic congestion.

[@zaboomafia]

Thanks Chris! We were able to fix a problem with our database connection from our client. We essentially needed to increase the keep alive interval.

[@ChrisGreer]

That's awesome James! Exactly the reason why this channel is here. Happy to hear it helped you.

[@brosjay94]

Great video. I keep understanding some more everything I watch this

[@kaus2005007]

Excellent Chris

[@williammurray588]

Excellent short and very useful courses. Nice Job

[@1einszweidrei]

Excepcional content, Chris!

[@PaulMansfield]

very useful video. I didn't know you could add the tcp time-since-previous-frame as a column!

[@ChrisGreer]

Glad it was helpful!

[@amirahmed1404]

Great 👍 explanation as always. Thank you Chris.

[@ChrisGreer]

Thanks as always Amir!

[@maitongm]

again, very useful!!

[@Phantasia.Official]

This explanation was very useful, thank you.

[@ChrisGreer]

Thank you for the comment!

[@Eskimoz]

L'angle est très bon c'est parfait !

[@yuriw777]

Great video thx! If I want to look for a string used in google search or any browser form submit, how would you do it?

[@hangeroo2439]

Thanks for yet another informative video, Chris. Keep 'em coming! I was wondering if I can ask you for some wireshark insight. I am trying to resolve an issue at a school district where they are having issues administering graphics-intensive tests to their students utilizing chromebooks (they would get delays, processing circle, etc.). I had someone look at the wireshark trace and he said, "I see a few TCP packets out of Sync, some with zero length, some spurious-retransimissions, and loads of “TCP segment of a reassembled PDU”. To me this points out to a device in the network, that’s sitting between the internet and the customer’s network (be it a firewall, proxy server, or any security appliance), which is capturing (Analysing?) every packet transiting, but not coping with the sheer traffic, which is introducing instability in the network." Would you agree with what he assessment? I am curious what percentage of out of synch packets, zero length, spurious-retransmissions, etc., would point to it being any of those devices or how would I look for which particular device is causing the problem. The district did mention they had jitter on their firewall and are taking a long time to get information back from Cisco. I asked them a while back if they had a proxy server and they said no. I then asked if maybe their ISP had a proxy server set up and asked them to have the ISP trace the traffic. They never said definitively that there was not a proxy server on the ISP side, but did mention something about traffic shaping from there. Just wondering if you can point me in the right direction so I can help them fix the problem of the stress they deal with while students are testing.

[@ChrisGreer]

Hey Hang eroo - Sure, of course, Please contact me on my website www.packetpioneer.com or email me direct - [e-mail] - thanks!

[@upelister]

Thank you.

[@nileshpardeshi6279]

Very helpful 👌 thanks

[@ChrisGreer]

No problem 👍

[@tanuavi98]

how to get time since previous frame column?

[@IaCnetLabs]

Great video, thanks! I'm willing to check what if the client is sending PSH flagged packet after 35 secs from the previous packet. Is this something that I need to check on the client side? In my case, App server (app01) is contantly talking to a DB Server (db01), and randomly delaying the response by 34 seconds, and after 34 seconds, the app01 is sending PSH,ACK to db01 and resuming the connection. I'm a bit confused where should I look for the problem. Is it app01 that's having problem or running low on resource or getting highly consumed, OR its the db01. Any suggestion would be highly appreciated. Thank you!

[@antonfernando8409]

very cool.

[@balajimohanakrishnan743]

Hi Chris, How did you create the Delta Column?

[@ChrisGreer]

Hello Balaji - You can see how in this video - kzbin.info/www/bejne/fHmyaYaagM6anrs

[@balajimohanakrishnan743]

Thanks Chris!

[@MariaSanchez-lb4kp]

Thank you! YOur video helped!

[@ishitashakya7767]

How come only after coversation filter delta value and time since previous frame value got same .....

[@ChrisGreer]

Hello! That is because before filtering there are multiple TCP conversations in parallel. Time since previous TCP frame is in context of the TCP conversation, but delta time shows all protocols regardless.

[@Thad811]

Curious as to why use the "Time since previous frame..." as opposed to just using the Delta time?

[@ChrisGreer]

As soon as you have more than one TCP connection in parallel in a trace file, your delta times won't give you the true delay in context to the conversation. So the time since previous frame gives you the in-context delay that you can locate delays with. Give it a shot on a larger trace file and you'll see the difference. Thanks for the comment!

[@Thad811]

Thank you!

[@ruimeireles1695]

I'm using Wireshark version 2.2.1 on Mac, and I don't have the "time since previous frame" shown in the TCP header. Is that something I need to enable?

[@ruimeireles1695]

Ok, I found out. You need to right click on the TCP line, go to the protocol options and enable Timestamps.

[@ChrisGreer]

Yes - you may need to enable the "TCP timestamps" in TCP preferences. Just right click any TCP packet on the TCP header itself in the detail view, select protocol preferences, and then you should be able to select "Calculate Conversation Timestamps"