site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1248779053; bh=sy3Yoo+WppZfwTgCZ3JKo9VMh4yuuP9HgDCvxGOO2u0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ONnFQwMcWb0bJJ80LSrLCyCfUzJSfjRtDHwfm4Jjn4l+meUsE7R4/qLt5Q2xRPAtf f3pEfKCib+mB4t9o0AETifMnw/pyjrFy+QNEGMMHQKV9rJLvpcflJYcEZpQsf2oCZV UJ4F/oecKivdkG/kYF34vhX8+H+qpaugphTbt2TI= User-agent: Thunderbird 2.0.0.19 (X11/20090105) Brendan Creane wrote: The code block that does the pullup is: if (mbuf_len(m) == ifnet_hdrlen(interface)) { err = mbuf_pullup(&m, sizeof(struct iphdr)); Rather than just pulling up 20 bytes, you should dereference the IP hdr and pull up the actual size of the hdr (which can be longer than sizeof(struct iphdr) if there are options). 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. What does the mbuf chain look like at this point? Drew _______________________________________________ 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