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
