I have fixed this in SVN 19669 so this should work again.
Brent, Ed,
Can you check the wiki for TCP to make sure this feature is documented
properly and that there are useful examples on how one can use this
feature and why one might want to use it?
Since you find this feature useful (as did the others that have
noticed it went missing in the big analysis rewrite and cleanup) it
would be very useful if someone that does use the feature could look
at the wiki and make sure it is properly documented both what it does
and why it is useful so others can also benefit from it.
To make it more accurate would be to enhance it to ONLY collect the
RTT for PSH segments (since tcps are not doing delayed-ack on such
segments) and only if there were no retransmissions between the
datasegment and the ack.
That is something for later though...
best regards
ronnie s
On 10/23/06, Ed.Staszko@xxxxxxxxxxxxxxxxx <Ed.Staszko@xxxxxxxxxxxxxxxxx> wrote:
Has there been any movement to re-introduce the SEQ/ACK breakout into
Wireshark?
We found this to be one of the most valuable capabilities in Ethereal and
used it for finding network times for remote subnets.
Below is a typical portion of a tethereal script that was used for getting
an RTT for only the TCP handshake.
This proved very valuable in quickly separating out an application-related
delay versus a network delay
and could keep a running file of network response times, especially
valuable when limited to a specific remote subnet.
This example, of course, relied on activation of the TCP relative sequence
number feature.
-z io,stat,60,AVG(tcp.analysis.ack_rtt)"((tcp.flags.syn==1 or (tcp.seq==1
and tcp.ack==1 and tcp.len==0)) and tcp.analysis.ack_rtt"
If anyone is working on restoring this capability, please add my request to
the list.
Ed Staszko
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users