https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6114
--- Comment #4 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2011-07-18 14:05:55 PDT ---
(In reply to comment #3)
> Created an attachment (id=6660)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6660) [details]
> Capture file including ICMP timestamps from XP machines
Thanks for the capture file. Well, there are actually a couple of problems
here:
1) The originate timestamp could be in big endian (BE) or little endian (LE)
format. Currently it is assumed to be BE, but this is not correct.
2) The receive and transmit timestamps could be in BE or LE formats,
independent of the originate timestamp. Like the originate timestamp,
currently it is assumed to be BE, but this is not correct.
I have played around with some heuristics that seem to work well under most
conditions but are likely to fail (or work by pure luck) under some corner
cases. Those corner cases concern rollover since all 3 timestamps - originate,
receive and transmit - are milliseconds since the start of the day (so
essentially mod 86400000). This means receive and/or transmit timestamps could
be less than the originate timestamp, but being less than the originate
timestamp does not necessarily constitute a rollover since it might just be due
to clocks not being synchronized, which is likely the case as seen in frame 8
of the capture file provided.
So what we're left with is either some ugly heuristics to try to figure all
this out (and probably getting it wrong sometimes), or we add some timestamp
endian preference items, which is also ugly and not ideal IMO because it's not
automatic and you get one or the other, never both, within a single capture
file.
The patch I will attach implements the ugly heuristics. If no complaints, I'll
commit it after I let it simmer a bit.
[Begin rant]
I really don't know why everyone seems to have ignored the endianness when it
comes to ICMP. I first experienced this mess when dealing with sequence
numbers and Identifiers. To quote (yet again) from the opening paragraph of
RFC792:
ICMP, uses the basic support of IP as if it were a higher
level protocol, however, ICMP is actually an integral part of IP, ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Being "an integral part of IP", it is only logical that it use the same byte
ordering as IP, namely network (big) endian order as specified in Appendix B of
RFC791: http://tools.ietf.org/html/rfc791#page-39.
[End rant]
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
