Wireshark-bugs: [Wireshark-bugs] [Bug 5770] Add conversation tracking to ICMP.
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.
