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 > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
