Re: NKEs on Intel-based Macs
Re: NKEs on Intel-based Macs
- Subject: Re: NKEs on Intel-based Macs
- From: "Peter Sichel" <email@hidden>
- Date: Wed, 16 Aug 2006 11:33:05 -0400
On 8/15/06, Josh Graessley wrote:
> 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.
There's still a little ambiguity here I'd like to clarify.
Referring to Steven's "TCP/IP Illustrated, Volume 2 The Implementation"
The 16-bit fields in the IP header are converted to host byte order
in ipintr (ip_input.c) page 214. Specifically the packet length,
identifier, and fragment offset:
NTOHS(ip->ip_len);
NTOHS(ip->ip_id);
NTOHS(ip->ip_off);
On output, they are converted back to network order in ip_output as
shown on page 229 (ip_id) and page 233 (ip_len, ip_off). I didn't
notice any other fields in the IP header that are byte swapped in place
during ip_input or ip_output processing. Searching the Darwin sources
for "NTOHL(ip->" (case insensitive) suggests they are not swapped in place.
As Ron noted previously, this may not matter with respect to the
checksum computation, but I'd still prefer to avoid unnecessary code
that confuses the issue. If I understand correctly, only the 16-bit
ip_len field needs to be swapped to host byte order before calling
mbuf_outbound_finalize. Both interface filter and ip filter NKEs sit
below ip_input and ip_output processing.
Yours in better understanding,
- Peter Sichel
Sustainable Softworks
_______________________________________________
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