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.
___________________________________________________________________________
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
