Re: mbuf_outbound_finalize() reports packet length is less than mbuf length
Re: mbuf_outbound_finalize() reports packet length is less than mbuf length
- Subject: Re: mbuf_outbound_finalize() reports packet length is less than mbuf length
- From: Brendan Creane <email@hidden>
- Date: Mon, 27 Jul 2009 22:03:34 -0700
Kevin,
I looked again at in_delayed_cksum_offset() and I think you're right
about mbuf_pull() as a work-around. I've got code that does a pullup
of the ip header when the first mbuf only contains the header -- I
know this isn't a general solution, but it seems to correctly identify
packets from OpenVPN that in_delayed_cksum_offset() complains about.
Unfortunately, I see a panic later on when the pulled-up packet goes
to the loopback driver:
panic(cpu 0 caller 0x0021B170): "lo_output: no
HDR"@/SourceCache/xnu/xnu-1228.12.14/bsd/net/if_loop.c:205
The code block that does the pullup is:
if (mbuf_len(m) == ifnet_hdrlen(interface)) {
err = mbuf_pullup(&m, sizeof(struct iphdr));
if (err != KERN_SUCCESS) {
printf("drv::Filter::pkt_out() - mbuf_pullup err=%d\n", err);
return EJUSTRETURN; // "swallow" the packet -
mbuf_pullup frees the mbuf on failure
}
}
It looks like mbuf_pullup() correctly sets the "PKTHDR" flag when it
allocates a new mbuf and the original mbuf has that bit set. So the
reason for the panic isn't clear to me, at this point.
cheers, Brendan
On Mon, Jul 27, 2009 at 4:43 PM, Kevin Brock<email@hidden> wrote:
> Brendan Creane wrote:
>>
>> I was hoping for a little while that just pulling in the first few
>> bytes of the ip header and then letting in_delayed_cksum_offset()
>> defragment the ip header would help, but I think
>> in_delayed_cksum_offset() is broken in that case as well.
>>
>
> It looks like it will copy the IP header into a separate buf, m == m0, and
> it won't mess with the value of ip_offset, so the math farther down will
> work... Why do you think there will be a problem in that case? Issues with
> m_copydata?
>
>> I've filed a radar bug for this problem, so maybe outbound_finalize()
>> will be usable in Snow Leopard!
>>
>
> Other bug's have been filed, so don't get your hopes up... We won't know
> for sure until we see the SL sources for those functions. Remember that the
> mbuf_pullup thread was two years back.
>
> Kevin
>
>
_______________________________________________
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