Another thing I noticed is that ICMP echo requests from my Windows XP
SP3 PC always set the ICMP Identifier field to 0x0400. So, if we do
think it's a good idea to try to determine endian-ness, we might also
have another preference to look for that value as the "little-endian"
identifier. But I don't know if all versions of Windows use 0x0400 for
the identifier or not. In any case, as long as all versions of Windows
use only a fixed value for the identifier and never change it, we could
introduce 3 new preference values to help determine endian-ness:
1) Little-endian: Y/N (default=NO)
2) Use Identifier to heuristically determine endian-ness: Y/N
(default=NO)
3) Little-endian Identifier: 0x0400 (default, only applicable if #2 =
YES)
So, if #1 preference is set to YES, the ICMP packets will
unconditionally be dissected assuming little-endian, but if it's set to
NO, then if #2 is set to YES, then only the ICMP packets whose
Identifiers match #3 will be dissected assuming little-endian and all
others will be dissected assuming big-endian. This would allow mixed
big-endian and little-endian packets to be dissected properly in the
same capture file, such as the one I'm looking at (except in the one
case where a big-endian identifier matched what was set in #3 preference
above). And of course if both #1 and #2 were set to NO, then all ICMP
packets would be dissected as they are today, namely big-endian.
Thoughts?
- Chris
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> bounces@xxxxxxxxxxxxx] On Behalf Of Maynard, Chris
> Sent: Friday, September 18, 2009 4:49 PM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] ICMP and endian-ness issue
>
> Yes, but RFC 792 also says in the Introduction:
>
> ICMP, uses the basic support of IP as if it were a higher
> level protocol, however, ICMP is actually an integral part of IP,
> and
> must be implemented by every IP module.
>
> So if ICMP is technically an integral part of IP, then it follows that
> ICMP should use the byte ordering as defined by Appendix B of RFC 791
> ... shouldn't it?
>
> It's clear that the intent was to increment the sequence #, so IMO,
> Windows got it completely wrong in this case.
>
> > -----Original Message-----
> > From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> > bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
> > Sent: Friday, September 18, 2009 4:26 PM
> > To: Developer support list for Wireshark
> > Subject: Re: [Wireshark-dev] ICMP and endian-ness issue
> >
> >
> > On Sep 18, 2009, at 1:07 PM, Maynard, Chris wrote:
> >
> > > 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.
> >
> > RFC 792 says
> >
> > Sequence Number
> > If code = 0, a sequence number to aid in matching echos
> and
> > replies,
> > may be zero.
> >
> > and
> >
> > The identifier and sequence number may be used by the echo
> sender
> > to
> > aid in matching the replies with the echo requests. For example, the
> > identifier might be used like a port in TCP or UDP to identify a
> > session, and the sequence number might be incremented on each echo
> > request sent. The echoer returns these same values in the echo
reply.
> >
> > which just says "might".
> >
> > RFC 1122 (Requirements for Internet Hosts -- Communication Layers)
> > says nothing about the sequence number field.
> >
> > So, while it's a bit surprising, I wouldn't call it completely
wrong.
> >
> > > 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?
> >
> > That might be reasonable. It's really per-sending-host, but we
don't
> > yet have any mechanism for specifying per-conversation properties.
>
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.
