Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] ICMP and endian-ness issue

From: "Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>
Date: Fri, 18 Sep 2009 17:41:36 -0400
It might ... but as Guy correctly pointed out, the RFC only states that
"the sequence number might be incremented on each echo request sent."
So theoretically (and for all I know, in actuality) there could be an
implementation of ping out there that does not simply increment sequence
#'s, but instead picks some random value or picks who knows what. 

BTW, something I didn't mention previously:  With both Linux and
Windows, it looks like the Identifier is sent in little-endian format as
well.  Well, with Windows it's hard to know for sure because it's always
the same value, 0x0400, but I'm willing to bet they sent it as little
endian.  With Linux, the Identifiers increment by 1 for each ping
session, but only if you interpret them as little endian values.
Bummer.  The Identifiers are not as important as the sequence #'s I
guess, but on Linux at least, they would tell you the number of ping
sessions that were run by computing the difference between the first
identifier and last identifier in the capture file.

- Chris

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> bounces@xxxxxxxxxxxxx] On Behalf Of Stephen Fisher
> Sent: Friday, September 18, 2009 5:24 PM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] ICMP and endian-ness issue
> 
> 
> On Sep 18, 2009, at 2:49 PM, Maynard, Chris wrote:
> 
> > 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.
> 
> Would it help to introduce something similar to the relative TCP
> sequence numbers in the TCP dissector?  I know it seems like a lot of
> work to work around weirdness in Windows, but it's something to think
> about.
> 
> 
> Steve
> 
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.