Re: mbuf_outbound_finalize bug?
Re: mbuf_outbound_finalize bug?
- Subject: Re: mbuf_outbound_finalize bug?
- From: "Bhavesh Davda" <email@hidden>
- Date: Thu, 21 Dec 2006 18:55:36 -0800
So I did this from my iff_output_func callback:
mbuf_get_csum_requested(*data, &csumFlags, NULL);
if (csumFlags) {
ipHdr = (struct iphdr *)((uint8 *)mbuf_data(*data) + ETHER_HDR_LEN);
if (ipHdr->tot_len > mbuf_pkthdr_len(*data)) {
/* ip_len must be in network-byte-order. Byte-swap it. */
ipHdr->tot_len = ntohs(ipHdr->tot_len);
swapIpLen = TRUE;
}
mbuf_outbound_finalize(*data, PF_INET, ETHER_HDR_LEN);
/* byte-swap ip_len back. */
if (swapIpLen) {
ipHdr->tot_len = htons(ipHdr->tot_len);
}
I *think* this is what your suggestion was.
This makes the kernel panic! I attached to the kernel and examined the
mbuf, and it looked totally messed up. Several pointers were pointing
to la-la land, the data in m->m_hdr.mh_data was munged from its
original values, etc.
The same was the case (messed up mbuf) when I set a breakpoint after
mbuf_outbound_finalize() and examined it, on a non-panic'ed kernel.
What am I, as poor KEXT author, doing wrong? The i386 version of
in_cksum_skip() is too hard for a simple minded person like me to
figure out :)
Thanks!
- Bhavesh
On 12/20/06, Adi Masputra <email@hidden> wrote:
On Dec 20, 2006, at 8:37 PM, Bhavesh Davda wrote:
> Thanks, Adi,
>
> So how do I do the workaround (byte-swap ip->ip_len in iff_output_func
> before calling mbuf_outbound_finalize, and then byte-swap it back), in
> a "future proof" way, so I don't have to reverse this workaround when
> Apple fixes the bug?
>
In theory you won't have to do anything; the stack should detect
if the length has been reversed by the filter and internally do
the byte-swap (from network to host) only if necessary prior to
calculating the transport checksum. Likewise, it will do the
host to network byte-swap of that value (internally) for the
IP header checksum calculation. In any case, the length in the
IP header of the packet will be restored to what the filter has
set it prior to calling the routine, upon return. That way the
packet won't end up incorrect should the filter reverses the
length back to network byte-order prior to sending it down.
With the fix in place, the only redundant work done by your filter
would then be the IP header checksum calculation though it shouldn't
cost too much when compared to the cost of checksumming the payload.
(I.e. without the fix, this step is necessary. With the fix, it's not,
but it won't hurt as long as your code does the right computation.)
Adi
> Or the fact that my NKE has to work on both older and newer kernels?
>
> Thanks!
>
> - Bhavesh
>
>
> On 12/20/06, Adi Masputra <email@hidden> wrote:
>>
>> On Dec 20, 2006, at 6:17 PM, Bhavesh Davda wrote:
>>
>> > When calling mbuf_outbound_finalize() to compute the incomplete
>> > TCP/UDP checksums on the mbuf from my iff_output_func (interface
>> > filter output function), I kept getting messages from the kernel
>> > "cksum: out of data".
>> >
>> > Looking at the xnu-792.13.8 source, it looks like the underlying
>> > in_cksum_skip, called from in_delayed_cksum_offset, expects the
>> ip_len
>> > field in the IP header to be in host-byte-order, while in
>> reality the
>> > mbuf handed to my iff_output_func had the ip_len field in the IP
>> > header correctly populated in network-byte-order.
>> >
>> > What is my iff_output_func to do in such a situation?
>>
>> This is a known bug and a fix is already in order. Assuming that
>> you call this from an interface filter, and that only the transport
>> checksum is to be recomputed, you should be able to byte-swap the
>> IP length, call mbuf_outbound_finalize() and restore the IP length
>> back to the network-byte order. If the driver offloads IP header
>> checksumming, and if this is an IPv4 packet, then you would need
>> to recompute the IP header checksum yourself prior to sending the
>> packet downstream. Once the fix is made available, you will no
>> longer need to do any of the above.
>>
>> (Also note that this issue does not exist for PPC.)
>>
>> Adi
>>
>> >
>> > Thanks!
>> >
>> > --
>> > Bhavesh P. Davda
>> > _______________________________________________
>> > Do not post admin requests to the list. They will be ignored.
>> > Darwin-kernel mailing list (email@hidden)
>> > Help/Unsubscribe/Update your Subscription:
>> 40apple.com
>> >
>> > This email sent to email@hidden
--
Bhavesh P. Davda
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden