Re: NKEs on Intel-based Macs
Re: NKEs on Intel-based Macs
- Subject: Re: NKEs on Intel-based Macs
- From: Josh Graessley <email@hidden>
- Date: Tue, 15 Aug 2006 16:05:17 -0700
The actual checksum value may be endian agnostic but the code that
calculates it is not. The code looks at ip->ip_len to determine how
much data to checksum. It just bails when it runs out of data in the
mbuf chain and prints out an error. This can still lead to checksum
errors though depending on what the ip_len value was. For example, a
packet of length 1280 will not receive the right checksum because the
code will only checksum 5 bytes. As long as the byte swapped value is
larger than the packet length and the mbuf chain has the right number
of bytes, the checksum should be alright just by chance.
-josh
On Aug 15, 2006, at 3:51 PM, Ron Hunsinger wrote:
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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