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