The delta time column has always been one of the first things to add when configuring Wireshark. It shows the time between displayed packets, or captured packets, depending on how you set it up. It makes finding delays in conversations much easier to do - that is unless you are dealing with a trace file that has several TCP conversations in tandem. It may be that the time between packets looks good, but that is because the previous packet is a part of a different conversation from the one you are analyzing.
In this video we will look at how to use the TCP Timestamp information in the TCP header (added by Wireshark) to find delays in conversations, even when multiple connections are overlapping each other.
This can help us to quickly identify where the hold-ups are in conversations, getting to root cause faster.
Hope this helps when troubleshooting!
HI Chris. I have been tasked with troubleshooting a "communications broken" error message on a specific hardware device. We believe the error precedes the resulting issues that need to be fixed on the host server customer side files. Manual corrections have to be made, all the while clients are standing in line waiting to be served. We know that the server files needing to be corrected and the comm broken message happen on the same transaction. I have collected a wireshark trace using a sharktap, setup between the gateway and the hardware device. The error is intermittent and over the last 2 days I have been capturing but the error has not occured. However, I am seeing some interesting conversation between the host and hardware. Do you know anyone that would be willing to analyse this for me and offer an opinion as to the posibillity that there is evidence present in the trace that may be relevent to the communication breaks that have been intermittently occuring. I have an opinion, but will keep it to myself for now.