site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=k67LBO1kIS4wcUxxq3OjjZmB76EWqHXlsQyc6tksSgE=; b=doz8LW/cGGTMJ4JLENPO3GjIaCfRBSmDBHIGLChTZO7seydcuIfwxXyiF2fTw3bVyK X8T9vUnq7H3wGzmpFeVJmi1df76S4ljXE0iyarU5K/XULpu65HSyVkjYuMsMdvqyc99h u9S2xFwhE6boW/HAGYD8XmuNoS3NMgYS4EBu8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=K6T33MZd5+g4YbAnMne93ZQ7/PxjiJ8P+YbnwOY6HicltJsbDKly2MfVGPjfIAl3UF MKtYR7KAUcTzcNDjU8uIbW5v/PqSvkBOYQeJ7TJsdAwOHIZa4oEGpnzSH8UmCa6iKL+W ySzDyC00JqNxKPvERi9DgxKWdKGiqNJlfe7Pc= 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<bcreane@gmail.com> 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<apple@kevin.com> 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      (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/0xcafefeed%40gmail.com

This email sent to 0xcafefeed@gmail.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com