site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aXCELIwn4RYtPTry+zqwL5NDucVpZuEwE88tYHlxrQssVt8QNe5JH9hSqFFsyJhDvVm8iQXXyLviRlTse8mPli1jPxZd2ii3j+47bYmGxG8/owaMFOomBDvTWShCKXb4Kmi29g/ykYLlTpcsX9ZjWP5vIktB8YMnSIqk28wc2Ew= Since your module is an interface filter, the field(s) in the header(s) will be in network byte-order. All you need to do is to byte-swap the length at all times assuming it is an IPv4 packet. Okay. I'll treat this fact as an invariant. What will change is the expectation in mbuf_outbound_finalize() that the IP length field should be in host-byte-order. Well, you are already requesting the stack to perform software checksum calculation on the packet which includes the transport payload; in terms of per-byte cost that is much more significant than traversing the mbuf chain to safely obtain the 2-octets IP length in the header. :) Good point. So just to be clear: even if I *always* byte-swap the IP length to make it host-byte-order in my iff_output_func before calling mbuf_outbound_finalize, it will work now (10.4.8) *and* in a future kernel where mbuf_outbound_finalize and friends have been fixed? In other words: how do I write code to figure out that the issue has been fixed, and no byte-swapping is necessary any more? Thanks! -- Bhavesh P. Davda _______________________________________________ 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... the fix is already in order. This email sent to site_archiver@lists.apple.com