Leave a Comment:
That’s a good point. If you want the sequence numbers in the graph to match the sequence numbers in the trace, then enable relative sequence numbers. Though I would argue that that actual sequence number in the graph isn’t all that important.
Future videos will make extensive use of the tcptrace graph and will show good and problematic graphs.Reply
What version of Wireshark is this…? I have never seen three lines in any version I’ve had.
Seems like the new version is less capable…
I have a really strange throughput graph…is it possible to upload an image?
Just figured out that I was not zoomed out far enough to distinguish the ACKs from the segments…R/FritzReply
My TCP knowledge is very limited so I’m trying to understand the line when you say “The top line represents the calculated receive window of the client. This is the ACK number plus the current advertised receive window.” Can you elaborate this and isn’t the receiver window calculated from the scale factor in the HS?
thank you for taking your time to share such wonderful knowledge. Please make more ;) these are very helpful for my job.Reply
Yes, the receive window is calculated from the scaling factor. However, in the context of this graph, we take that calculated receive window and add the current ACK number to get the receive window line on the graph. This way we get a visual representation of how much space there is in the receive buffer. The more space there is between the data line and receive window line, the more space there is in the buffer.Reply
A huge factor in actually seeing the graph correctly will depend on whether you have an inbound or outbound packet selected in the packet window. If you dont see anything try clicking a packet from the other direction in the conversation. Wireshark 2.x has a button called Switch Direction to make this more convenient. They also let you select the stream directly in the TCPTrace window. Very handy stuff. Thanks for the good article, the WCNA book doesnt break this down as well as you did!Reply
[…] Wireshark’s tcptrace analog showed that bytes in flight were not limited by the receive window size. This […]Reply
regarding time sequence graph while I still don’t fully have a grasp on it I would suggest telling folks to change tcp sequence number to relative sequence numbers because (it appears at least) the sequence numbers line up on graph and trace
also, it would help me to see an example of a bad scenario and good scenarioReply