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: mm w <email@hidden>
- Date: Tue, 28 Jul 2009 09:30:59 +0200
Hi Brendan, it looks like your mbuf is already gone or/and you face to
same issue over again,
you should really try what I put earlier to check the data.
if ((m->m_flags & M_PKTHDR) == 0)
panic("lo_output: no HDR");
can you tcp-dump a sample?, I think it would be easier to trace for
everyone without using OpenVPN,
especially for people who don't have a vpn setup on their local machines.
Best,
On Tue, Jul 28, 2009 at 7:03 AM, Brendan Creane<email@hidden> wrote:
> 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
>
_______________________________________________
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