https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4014
--- Comment #29 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-09-17 05:01:04 PDT ---
(In reply to comment #28)
> ...which (the user of a random number as the ICMP ID, that is) renders the
> whole byte-order issue moot; there's not much reason to care about the
> byte-order of a random pile of bits.
Not necessarily. If you generate a random pile of bits for the identifier and
use that identifier on the local machine - even printing it to the screen for
example, which ping could do - and then capture those same ICMP echo
request/response packets using those random pile of bits for the identifier
field, it would nice if they matched.
> Not that the byte-order issue is that relevant in any case; one could argue
> with people putting out little-endian ICMP IDs until one is blue in the face,
> but until they stop, and the last release putting out little-endian ICMP IDs
> ceases to be on any network, users and the applications they use will either
> have to not care about the byte order of ICMP IDs or will have to cope with
> little-endian ICMP IDs.
This I agree with. The fact is that we are stuck with ICMP packets using both
big and little-endian identifier and sequence number fields with no reliable
method of accurately determining the endian. Which is why I gave up on trying
to add some heuristics.
Unless someone disagrees, I think this bug could be closed now?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.