Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jan 2005 16:45:53 +0300
From:      Gleb Smirnoff <glebius@freebsd.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        net@freebsd.org
Subject:   Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)
Message-ID:  <20050120134553.GB18668@cell.sick.ru>
In-Reply-To: <41EE2933.4090404@elischer.org>
References:  <20050117200610.GA90866@cell.sick.ru> <20050118183558.GA15150@odin.ac.hmc.edu> <41ED8D63.8090205@elischer.org> <20050119084526.GA5119@cell.sick.ru> <41EE2933.4090404@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
  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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050120134553.GB18668>