Re: mbuf_outbound_finalize() awkward on intel
Re: mbuf_outbound_finalize() awkward on intel
- Subject: Re: mbuf_outbound_finalize() awkward on intel
- From: Josh Graessley <email@hidden>
- Date: Tue, 10 Jan 2006 10:56:09 -0800
On Jan 10, 2006, at 5:57 AM, Andrew Gallatin wrote:
Josh Graessley writes:
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"
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.
-josh
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden