site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jan 10, 2006, at 5:57 AM, Andrew Gallatin wrote: There were some fixes related to this that went in. It is possible this is fixed. You should file a bug either way to make sure that this is fixed. Ideally, everything in the packet that a kext sees will be in network byte order and every function in the KPI should take packets that contain data in network byte order. Anything else would be a huge mess. Hmm.. That's definately not the case for mbuf_outbound_finalize(). By the time a packet makes it through ip_output() to dlil_output), the stack has put the ip header into network byte order. However, in_delayed_cksum_offset(), which is what is ultimately called by mbuf_outbound_finalize(), expects the ip header in native byte order. Maybe something special happens for interface filters, but I'm munging this from a driver so I don't get the benefit of any magic which may be done for interface filters. In my opinion, it is more of a documentation bug for mbuf_outbound_finalize(). It should probably have a sentence which says "For PF_INET packets, the ip header's ip_len field must be in host byte order" -josh _______________________________________________ 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 Josh Graessley writes: That is one possible solution. In my opinion, the bug is that the any part of a packet would be in host byte order when it's passed off to a filter. Whether you're implementing an IP filter or an interface filter, the packets should be in network byte order. mbuf_outbound_finalize should handle the packet as such. smime.p7s