[TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)

Julian Elischer julian at elischer.org
Wed Jan 19 01:32:44 PST 2005


Gleb Smirnoff wrote:
> On Tue, Jan 18, 2005 at 02:27:47PM -0800, Julian Elischer wrote:
> J> firstly.. I was thinking that there are several good ways to mesh the 
> J> ipfw/divert/netgraph
> J> stuff.
> J> 
> J> Firstly there is the possibility of making the ipfw stuff a netgraph 
> J> node itself..
> 
> Yes, but this is a separate node. I'm working on a node doing opposite
> thing, it will allow to filter netgraph traffic using an arbitrary
> ipfw chain.
> 
> J> (yes I know there is such a node (based on ipfw-1) out there.)
> 
> If you are speaking about a node from BWMAN, then it is not based on
> ipfw. It uses its own filter engine, AFAIK.
> 
> J> then as for getting stuff out of ipfw, maybe divert itself could be 
> J> changed to be
> J> a netgraph method. In this way, you'd open netgtraph sockets instead of 
> J> divert sockets.
> J> 
> J> Alternatively there could be a possibility where netgraph could open 
> J> hooks of a particular number
> J> and that would be the equivalant of openning a divert hook of that number..
> J> 
> J> Looks good but I'm not convinced that it needs a whole new keyword of we 
> J> tap in through the divert mechanism.
> 
> Divert is a socket, and ng_ipfw is not. We tap thru a direct call to netgraph.
> 
> I think, divert is designed for userland interaction. It is possible to use
> it for netgraph (via ng_ksocket), but this adds overhead of passing the socket
> layer, and I believe not all bugs are caught in this setup. That's why I prefer
> two different keywords, which do completely different things.

I'm not sure they do two different things..  Each represents a place to send 
packets.
If each active divert socket number had a pointer to the module to which it
was attached then  you could divert to either in-kernel netgraph targets or
to userland socket based targets.  Currently of you divert to a divert
'port number' and nothing is attached to it, the packet is dropped.
If a divert socket is attached to it, it is sent ot teh socket.
I would just suggest that is not a great leap of imagination that
attaching to a hook named 3245 would attach a netgrpah hook to the ipfw
code in the sam enamespace as the divert portnumber, and that a
subsequent attempt to attach a divert socket to that port number woild
fail. The packets diverted there would simply go to the netgraph hook
instead of going to a socket or being dropped.

> 



More information about the freebsd-net mailing list