site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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: Darwin-dev@lists.apple.com Subject: Re: mbuf data access On Jun 7, 2006, at 9:34 AM, jy.cases@mac.com 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. - mbuf_len() on a mbuf (marked as MBUF_EXT) in a mbuf chain is a valid length ? _______________________________________________ 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... - 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 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. This email sent to site_archiver@lists.apple.com