Fwd: mbuf data access
Fwd: mbuf data access
- Subject: Fwd: mbuf data access
- From: Stephane Sudre <email@hidden>
- Date: Thu, 8 Jun 2006 10:29:40 +0200
Was sent to the wrong list
Begin forwarded message:
From: Josh Graessley
Date: 7 juin 2006 19:26:36 GMT+02:00
To: "jy.cases"
Cc: email@hidden
Subject: Re: mbuf data access
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.
_______________________________________________
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