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:cc:content-type :content-transfer-encoding; bh=6g5PPsDq9vgppV4BobrmYOlZk/FLfuLkZnmO39DjxQ8=; b=twm096N9Vx40jFof7A+KtSv93ep21tqoaiLXMbr+3OkMW4CLpXgFi3gOhIYNdrv1x7 eqNO1rRlbTPnrCl6FkSwLAGulbRZwMgnVTF3V9WRQSU6EicgNEucJp/2OG9nulj4LpvQ 3PjvttQdaFmUTTm03zI1D8Lf7dWkecr2aQ4CY= 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 :cc:content-type:content-transfer-encoding; b=YgTyDJFwX/ePB8U156OFKVMQNtt57scZhuEsSL+JnYi3g+EOrf10paggjMEHP73q61 Jl4hN1p18mEhFZWZPjWjmMKLEthrmdNHpGt9dokfgaym6EreD8NxCL6JQyO6+YvZwFlm KNNMlt1KaZi3gU6NpisjH6DPgRvjiMtsTFHhs= 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/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com