On Sunday, June 20, 1999 7:22 AM, Luigi Rizzo [SMTP:lu...@labinfo.iet.unipi.it] wrote: > > This means that IP filters need to grab some of IP packets, process > > them on a specialized prosessor and then re-inject them into the IP > > packet stream. That is, the filter may decide to convert the packet, > > but it doesn't have it ready-to-go when it has to return. However, > > it may have it ready at some later time, possibly when it processes > > a hardware interrupt and sees that the co-processor has finished its > > work on the packet. Can ipfilter handle this? > > no idea about ipfilter, but i guess not -- in the case of ipfw i > did have to implement exactly this funcionality for dummynet and i > ended up putting it _outside_ dummynet (i.e. in the callers routines, > ip_input(), ip_output() and bdg_forward() ) . > > this might ease life to those who want to replace ipfw with ipfilter > for dummynet or similar things, if nothing else.
Thank you, Luigi. Could you please help me with some basics? Our IPSec product intercepts outbound IP packets and usually changes them in the way that makes them bigger. It performs the reverse operation on the inbound packet stream. I'm not quite aware of exact packet transformations, since my part of this port is to "hook" into the IP packet streams and provide the base for the main package. My first intention yesterday was to take the place of ipfilter, since IP protocol code seemingly had necessary hooks in place. I was thinking that, in ip_output(), I could just tsleep() in my filter, waiting for the co-processor to encode the packet and then wakeup() from the co-processor's ISR. (Am I right in thinking that ip_output() is always invoked during the system call and thus can sleep?) For inbound packets, tsleep() in ip_input() is not possible, so I was hoping to eat packets by placing then into an internal queue and then, in the co-processor's ISR, push them back to the IP input queue and to schedule network interrupt for IP (like net interface drivers do). (I was not quite sure whether the above idea was feasible, I would have to investigate this.) But the problem that stopped me is that, while ip_output() first invokes the ipfilter and then fragments the packet (which is good for me), ip_input() first invokes ipfilter and only then re-assembles the packet. At the first glance it looked weird but I soon realized that ipfilter is probably only interested in packet headers and the placing hook point there can improve performance by filtering out some packets prior re-assembly. However, this design defeats my idea (if I don't want to re-assemble them by myself, of course). If would be nice to have another hook point in a proper place _after_ the re-assembly stage of ip_input(). It would not cause much overhead if nobody has a hook installed. Please, if you've reached this place, tell me where I'm wrong. We already have our IPSec product fully functional in NT and we would love to port it to FreeBSD, however, despite the simplicity of our needs, I currently don't see a clear way of plugging it into any layer of the network stack. Between IP and network inferfaces, as it is done in NT? Our product does handle fragmentation and re-assembly. But the network interface drivers push packets directly into the IP queue, I'd have to modify the ether_input() and friends and probably meet some other unexpected implications. Adding the additional hook point seems to be the ideal solution for me. It would result in minimal efforts and minimal code size, and it is clearly much cleaner then any other place. The IP protocol driver is the ideal place for IP packet filters, after all. Since I'm new to Unix, I'm not sure if this is Ok to put this couple of operators directly to ip_input and tell our customers to do so before installing our product. What is the best way? Please, forgive me if I wrote some stupid things in this letter. Thank you, Stan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
