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.