Re: ipf_inject_input returns ENOTSUP
Re: ipf_inject_input returns ENOTSUP
- Subject: Re: ipf_inject_input returns ENOTSUP
- From: Josh Graessley <email@hidden>
- Date: Tue, 20 Sep 2005 13:37:26 -0700
On Sep 20, 2005, at 1:19 PM, Allan Hoeltje wrote:
I tried using ctl_send_func first but had a number of problems.
First, I
was not able to specify any options in the send call which my kext
could
then interpret as "outgoing" or "incoming" packet. I suppose my
kext code
could keep track of which IP address is used as the remote source
and decide
accordingly.
You could also potentially prepend a header that describes additional
information. Part of this information would indicate whether the
packet should be injected in or out. If you use sendmsg, you can fill
out an iov so you don't have to get the header and the packet data in
a contiguous block. You can use mbuf_adj in your kernel extension to
trim the header off once you're done with it and inject the rest of
the chain as is.
If I use ctl_send_func, will the mbuf chain contain a proper
M_PKTHDR in the
first mbuf? That is my biggest problem right now.
Yes, the mbuf chain will start with an mbuf that has the M_PKTHDR
flag set and the corresponding mbuf packet header fields filled out.
Using setsockopt to pass in a whole packet is less than ideal
Why is setsockopt less than ideal? Inspection of the source code
does not
reveal why this would be a poor choice.
This will require an extra copy of data or duplication of some tricky
code.
If your socket option passes a pointer to the data, you will need to
effectively duplicate the logic in sosend to allocate a chain of
mbufs with clusters where appropriate and copy in the data. You will
also need to setup the pkthdr fields correctly. This is complicated
stuff that is tricky to get just right. If you screw something up you
could panic the system. If someone smart figures out how you screwed
up, they could potentially exploit your mistake to attack the system
from the network.
If your socket option passes in the entire buffer, the kernel has to
allocate a buffer large enough to hold the packet. IP packets can be
up to 64k in length. You will then have to write similarly complex
code for allocating an mbuf chain that is large enough to store the
entire packet and copy the data.
I hope you're using ctl_enqueuembuf to send the packet
to your user app.
No, I am using ctl_enqueuedata to send the IP packet to my user app
because
I needed to include my own control information, such as: is it
incoming or
outgoing, was it removed from the IP stack (and thus needs to be
returned
for insertion), etc. I realize that ctl_enqueuedata duplicates the
mbuf
before sending it as flat (void *) data but is that too terribly
expensive?
That's not too bad. It would be more efficient to simply prepend the
data to the mbuf chain and then call ctl_enqueuembuf. Either one is
fine. I was just concerned that you were polling using a socket
option to receive packets as well.
-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