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
--
Dead stars still burn