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: Sat, 19 Sep 2009 00:23:57 -0400
After thinking about this some more, I decided to submit a new patch to
simply display the sequence #'s in both big-endian and little-endian
format.  This avoids adding new preferences and/or trying to guess at
the endian-ness.  The new patch and a screen shot depicting the Info
column is posted with bug 4014:
http://www.wireshark.org/lists/wireshark-dev/200909/msg00216.html.  Let
me know either here or in the bug report if this patch is sufficient.

Thanks,
Chris

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> bounces@xxxxxxxxxxxxx] On Behalf Of Maynard, Chris
> Sent: Friday, September 18, 2009 5:42 PM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] ICMP and endian-ness issue
> 
> 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.