https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4014
--- Comment #13 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-06-16 12:55:40 PDT ---
(In reply to comment #12)
> Yes, I was thinking about the "seq(be/le)=1/256" output. I don't have a good
> fix in mind, other than a preference enable/disable the LE entry.
What if you only have "Windows -> Windows" pings? In that case you might be
only be interested in the LE seq #'s and not the BE seq #'s. So, if you're
going to add a preference, maybe it should choose between BE, LE, or both
BE/LE?
BTW, the same *could* be done for the ID field. I've found that even with
Linux the ID field was incorrectly being sent in LE byte order as can be seen
in the attached screen shot of a ping from a RHEL5 system. The latest
implementation of iputils appears to fix this though.
On Linux, each new ping session uses the process ID of the ping utility itself.
But with a LE ID, it made it harder to match the actual process ID with the
ICMP packets. I didn't bother displaying the ID field in both BE and LE
formats, but who knows, it might possibly be useful.
And since the process ID is normally known by its decimal value, not its
hexadecimal value, maybe we could also switch its format to decimal, both in
the Info column and the packet details? With Windows, I'm not sure what it
chooses for the ID, but it always seems to be the same value, so I don't think
it would matter which base is used to display it.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
