Wireshark-dev: Re: [Wireshark-dev] ICMP and endian-ness issue
From: Jaap Keuter <[email protected]>
Date: Fri, 18 Sep 2009 22:38:50 +0200
Hi,

M$ has been known for not respecting the transfer format in other protocols too.
See packet-bootp.c line 3880 for instance. Still, this sequence # is not violating any standard, just counter-intuitive.
Thanx,
Jaap

Maynard, Chris wrote:
I am capturing ICMP traffic from both a Linux PC and a Windows PC using
a customized version of Wireshark with the changes to the ICMP dissector
from this bug report
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4014.

While doing this, I noticed that ICMP sequence #'s from a Linux PC
increase sequentially, as one would expect.  For example, 1, 2, 3, ...
The ICMP sequence #'s from a Windows PC is a different matter though.
As an example, Wireshark shows the following sequence in one of my
capture files: 7682 (0x1e02), 7938 (0x1f02), 8194 (0x2002), 8450
(0x2102), 8706 (0x2202), 8962 (0x2302).   The problem is obviously one
of endian-ness.  Quite surprisingly to me, it seems that Windows sends
ICMP echo request packets with multi-byte fields in little-endian
format.  This makes it a little difficult to track sequence #'s and
visually tell if a request and/or response is missing, out-of-order.

I guess it's impossible or nearly so to heuristically figure out if the
format is big or little endian.  Would adding a preference to specify
the endian-ness be a reasonable solution, with big-endian being the
obvious default?

Anyone else surprised to see little-endian sequence #'s in Windows ICMP
request packets?
- Chris