RE: ICMP packet size in host byte order on Intel Macs
RE: ICMP packet size in host byte order on Intel Macs
- Subject: RE: ICMP packet size in host byte order on Intel Macs
- From: "David Litwin" <email@hidden>
- Date: Wed, 1 Mar 2006 15:57:12 -0800
- Thread-topic: ICMP packet size in host byte order on Intel Macs
I'm a bit confused by your post, as my man page (OSX10.4.4, XCode2.2)
indicates it is in network byte order (because these fields are htons()
in the sample code), then goes on to indicate that in OpenBSD2.1 (what
does this mean for OSX?) they are also in network byte order. I didn't
see anywhere that indicated host byte order:
ip->ip_v = IPVERSION;
ip->ip_hl = hlen >> 2;
ip->ip_id = 0; /* 0 means kernel set appropriate value */
ip->ip_off = htons(offset);
ip->ip_len = htons(len);
Additionally note that starting with OpenBSD 2.1 the op_off and
ip_len fields are in network byte order.
And, so far as I can tell from my (new) testing, raw sockets are
completely network byte order.
What I hadn't noticed (until you mentioned Raw IP Sockets) that the code
I was using uses SOCK_DGRAM, not SOCK_RAW. Our production app runs as
root (requited to open with SOCK_RAW), but I'm presuming the code was
using SOCK_DGRAM so that it could be more easily debugged without having
to go through the trouble of running both the debugger and app as root.
SOCK_DGRAM has these as host byte order, which is expected and what I
was seeing. It's just the rest of my code was expecting it to be raw.
David Litwin
BigFix
-----Original Message-----
From: Vincent Lubet [mailto:email@hidden]
This is normal with for Raw IP Sockets, all the fields of the IP
header are in network byte order except for the fields ip_len and
ip_off that are in host byte order. This is documented in the man
page ip(4).
See
Vincent
On Feb 28, 2006, at 8:20 PM, David Litwin wrote:
> I am seeing a problem with ICMP socket packets having their size field
> in host order on the Intel Macs.
>
> A packet coming to a ppc mac will have a received size (from
> recvfrom())
> of 32 and a header starting with:
> 45 00 00 0c ...
>
> whereas the Intel Mac will get a packet of received size (from
> recvfrom()) of 56 and a header starting with:
> 45 00 24 00 ...
>
> subtracting 20 bytes from each received size to account for the packet
> header, one would expect the Intel packet to be:
> 45 00 00 24 ...
>
> Oddly, ping on the Intel Macs works fine, and I would have presumed
> this
> to cause it the same trouble it is causing me. Is it possible Apple
> fixed the Intel version of Ping around this, is ping doing something
> different, or am I missing some information that explains all of
> this in
> some other way?
>
> David Litwin
> BigFix
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden