Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5770] Add conversation tracking to ICMP.

Date: Fri, 15 Jul 2011 02:08:03 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5770

--- Comment #33 from Sake <sake@xxxxxxxxxx> 2011-07-15 02:07:59 PDT ---
(In reply to comment #30)
> OK, so I decided to take a look at trying to make use of the timestamp in the
> ICMP payload after all.  I got to thinking, "What if we have a HostA pinging
> HostB, with a host in the middle running Wireshark capturing the pings?".  In
> that case, the response time I'm computing is only the round trip of the 2nd
> leg of the journey and not the real end-to-end round trip time.
> 
> But, if HostA is placing a timestamp in the ICMP payload that reflects the time
> at which it sent the ICMP echo request, we should be able to make a reasonably
> good estimate of the total round-trip time, or service response time (SRT) to
> keep the notation the same as other protocols.  So given:
> 
>             1st leg                2nd leg
>  +-------+          +-----------+          +-------+
>  | HostA |          | Wireshark |          | HostB |
>  +-------+          +-----------+          +-------+
>      |                     |                   |
>      +---------------------+-------------------+
> 
>      t0 =================> t1 =================>
>                            t2 <================
> 
> t0: The ICMP timestamp payload
>     i.e., the time that HostA sends the ICMP echo request
> t1: The time that Wireshark receives the ICMP echo request from HostA
> t2: The time that Wireshark receives the ICMP echo reply from HostB
> 
> Knowing all 3 of these times, we can easily calculate the time it takes for the
> ICMP echo request to reach Wireshark.  That's simply t1-t0.  We can also easily
> calculate the SRT of the ICMP echo request/reply from Wireshark's perspective
> as t2-t1.  The only thing we don't know is the time it takes for the ICMP echo
> reply to reach HostA from Wireshark, but we can make a pretty good guess that
> it should take about the same time as the ICMP echo request took to reach
> Wireshark from HostA.
> 
> Thus, the estimate becomes: 2*(t1-t0) + (t2-t1)

That will only work when the clocks of HostA and HostWireshark are synchonized.
If HostA is 2ms behind HostWireshark, then yourcalculation will result in a SRT
that is 4ms higher than it really was.

The only way to "fix" that is to learn the RTT between HostA and HostWireshark
from other packets, but I think that goes to far to put in to Wireshark. If
people really need to know, they can do the match themselves :-)

Cheers,
Sake

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.