Timestamp from icmp data is incorrect in Wireshark v4.0.7-0-g0ad1823c
ICMP: Improve heuristic for data time
On Thu, Aug 17, 2023 at 9:51 AM Stefan Kleedehn <
sk@xxxxxxxxxxx> wrote:
Hello John,
thank you very much for your quick and detailed answer. I am using a
Linux iputils ping and pinging different hosts for days. If I understood
you correctly, the decision whether to interpret big-endian or
little-endian is decided per frame. And there are just different
guesses. It would be nice if there was an option to configure this in
the Protocol Preferences. Or the value for BE and LE is displayed,
similar to icmp.ident. Maybe there is someone who can and wants to
implement this suggestion.
Many greetings,
Stefan
Am 16.08.2023 um 18:28 schrieb John Sullivan:
>
> Haha! Yes.
>
> The problem is triggered by the specific value you have: 64dad964
>
> Note that the first and fourth bytes are the same, and the second and
> third bytes are almost the same.
>
> That value is on the wire here in little-endian order. The problem being
> both orders are possible and wireshark doesn't know which one is true, so
> it guesses.
>
> It guesses by trying big-endian first, and if the resulting value is more
> than one day away from the frame's capture timestamp then it switches to
> the little-endian interpretation. For a 32-bit unix time, a difference of
> 1 in the most significant byte is a difference of at least 6 months, and a
> difference of 2 in the next byte is a day and a half, so to be fooled you
> need the MSB to equal the LSB and the middle bytes to be within a
> difference of 1 of each other. This will happen, I believe, 4 times every
> day on average. So you have to be lucky but not especially so to be
> pinging at just those times.
>
> (Why? Well that timestamp isn't part of the RFC, in the RFC it's just
> opaque data that the server must echo verbatim back to the client. The
> client decides whether it's going to put a timestamp in there or something
> else, and the Linux iputils ping for example just memcpys a timestamp in
> so it goes in whatever the current host byte order is which makes pulling
> it out again a bit more convenient.)
>
> Not really a lot you could do about this. You could reduce the max delta
> to make it less common. You could assume little-endian first on the
> grounds that such hardware is more common. Or perhaps more common amongst
> people who don't understand ICMP well enough to avoid complaining about
> it. You could assume local host order first on the grounds that people are
> likely to inspect captures on similar hardware to that doing the pings, so
> it'll get noticed less.
>
> But it's decades too late to avoid the issue altogether.
>
>
> On Wednesday, August 16, 2023, 1:11:30 PM, Stefan Kleedehn wrote:
>> Hello all,
>
>> I have attached a pcap with 6 icmp echo requests. In frame 5 the
>> icmp.data_time is wrong. It looks to me that the order of the hex value
>> of the icmp.data_time field in frame 5, is interpreted incorrectly. For the other values it looks fine.
>
>
>> Many greetings,
>
>> Stefan
>
>
>
>
> John
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe