Julian, On Wed, Jan 19, 2005 at 01:32:35AM -0800, Julian Elischer wrote: J> I'm not sure they do two different things.. Each represents a place to J> send packets. J> If each active divert socket number had a pointer to the module to which it J> was attached then you could divert to either in-kernel netgraph targets or J> to userland socket based targets. Currently of you divert to a divert J> 'port number' and nothing is attached to it, the packet is dropped. J> If a divert socket is attached to it, it is sent ot teh socket. J> I would just suggest that is not a great leap of imagination that J> attaching to a hook named 3245 would attach a netgrpah hook to the ipfw J> code in the sam enamespace as the divert portnumber, and that a J> subsequent attempt to attach a divert socket to that port number woild J> fail. The packets diverted there would simply go to the netgraph hook J> instead of going to a socket or being dropped.
Well, I've considered this. We are going to have these negatives with this change: 1) require divert loaded/compiled, when we are going to work with a completely different thing. 2) Acquire & drop lock on divert pcb info for each packet going into netgraph. 3) Extensively hack divert_packet()... Let me explain. The place where we can tell whether we have a socket diversion or a netgraph diversion, is at the very end of divert_packet(). Before this place many things are done, which does not apply to a netgraph diversion. This hacking may bring bugs into divert infrastructure, and add extra CPU cycles for case of netgraph forwarding. I think saving one keyword for ipfw2 doesn't worth this hacks. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
