Re: NKEs on Intel-based Macs
Re: NKEs on Intel-based Macs
- Subject: Re: NKEs on Intel-based Macs
- From: Ron Hunsinger <email@hidden>
- Date: Tue, 15 Aug 2006 15:51:52 -0700
At 1:50 PM -0700 8/15/06, Josh Graessley wrote:
I have done a little more digging and I had it
backwards. The ip filter does pass the packets
with the headers in network byte order as it
should. The problem is that
mbuf_outbound_finalize calls a function that
expects the IP header to be in host byte order
to calculate the checksums
(in_delayed_cksum_offset). It looks like the
best solution is to swap the bytes in the IP
header to host byte order before
calling mbuf_outbound_finalize and swapping them
back after mbuf_outbound_finalize returns.
Are you sure that's an error? The reason the
internet standards specify that checksums be
calculated using ones-complement arithmetic is
that it's endian neutral. That is, if you have a
function
ushort onessum (ushort a, ushort b);
to compute the ones-complement sum of two 16-bit shorts, then
onessum (x, y)
and
ntohs (onessum (htons(x), htons(y))
and
htons (onessum (ntohs(x), ntohs(y))
all produce exactly the same value, whether x and
y are in network or host byte order. Thus,
routines to compute and/or check checksums can be
oblivious to byte order.
The only time you'll have a problem is if you
have a short where some of the bits are
significant but other bits need to be omitted
from the checksum calculation (treated as if
zero). (For example, at the end of an odd-length
TCP packet.) You have to be sure the mask you use
has the same endianness as the data, so it masks
off the right bits.
-Ron Hunsinger
_______________________________________________
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