Re: mbuf data access
Re: mbuf data access
- Subject: Re: mbuf data access
- From: Josh Graessley <email@hidden>
- Date: Wed, 7 Jun 2006 10:26:36 -0700
On Jun 7, 2006, at 9:34 AM, email@hidden wrote:
Hi all,
I'm writing some NKE UDP filter with packet mangling + packet re-
injection,
when i have a mbuf (in chain) with flags set to MBUF_PKTHDR i've got
an
access to data using MTOD(tMbuf, caddr_t), at this point every
things works
fine but when the mbuf in the chain is marked as MBUF_EXT nothing
work at all.
- How can have access to packet data ?
mbuf_data will give you access to the data stored in that mbuf. It is
possible the data is stored in multiple mbufs chained together. You
can call mbuf_next to get the next mbuf in the chain.
- mbuf_len() on a mbuf (marked as MBUF_EXT) in a mbuf chain
is a valid length ?
mbuf_len like mbuf_data works whether or not MBUF_EXT is set. MBUF_EXT
just indicates that the actual implementation of the mbuf is storing
the data in an external cluster and not in the mbuf data structure
itself. The one reason this would be important to a client of the mbuf
is the case where you may modify data. In some cases, the reference to
the external cluster may be shared. If this is the case, you will need
to duplicate the data before modifying it. This often happens with
data sent from a TCP socket. The TCP data sits in the socket's send
queue. mbufs are created to reference that data without copying it.
Your filter will see mbufs pointing to that referenced data. If you
did something like encrypt that data, you would be encrypting the copy
in the socket buffer. If this data was retransmitted, you would have
corrupted the data stream.
- when modifying such packets do i need to compute some checksums ?
Sometimes. At the socket filter layer, no. At the IP filter layer yes.
On the inbound path, you need to verify the original checksum
yourself. Discard the packet if the checksum is bad. If not, modify
the data. Once the data has been modified, calculate the right
checksum and call mbuf_inbound_modified. You can also modify the
checksum to account for the changes instead of checking the old one
and generating a new one. You still need to call
mbuf_inbound_modified. For more information, look at
mbuf_inbound_modified.
On the outbound path, you need to call mbuf_outbound_finalize before
you start modifying the packet. You will be responsible for modifying
the checksums once you have called this function.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden