On Thu, Jun 01, 2000 at 01:05:40PM -0600, John McDermott wrote:
>
> Hi,
>
> I've been using an old version and decided to compile 0.8.8 for a client
> under RedHat 6.2 When I look at ICMP Echo packets it looks as though
> the Sequence Number field is byte swapped (this because the sequence
> number under Ethereal goes 0, 256, 512,... while the client software
> sees it go 0,1,2,...). I did not see this on the mailing list, but
> IIRC, was alright in earlier versions. Am I confused or is Ethereal?
I think Ethereal assumes too much. I checked on my Linux system
(ix86, 2.4.0test1) and indeed the 2-byte value sent in the ICMP sequence field
is little-endian.
Ethereal is dissecting it as big endian (using pntohs()), since all
other fields in IP et al. are big endian (network order).
But after a careful reading of RFC 792, the ICMP RFC, it seems that
the Sequence Field is just a two byte number that the client
cares about, possibly, not not necessarily, incrementing it.
The pinged device simply echos the sequence field exactly as it sees it:
Sequence Number
If code = 0, a sequence number to aid in matching timestamp and
replies, may be zero.
<snip>
The identifier and sequence number may be used by the echo sender
to aid in matching the replies with the 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
request sent. The destination returns these same values in the
reply.
Notice that last sentence. The client is the only device which interprets
the sequence field, so it's up to the client on how he wants to encode
the sequence field. Apparently Linux doesn't convert the 16-bit uint
to network order, but keeps it in native order.
Can someone run a trace on a big-endian Linux box to confirm this? I'd
expect *those* sequence numbers to be in big-endian format.
--gilbert
