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

From: Gleb Smirnoff (glebius_at_freebsd.org)
Date: 01/19/05

  • Next message: Julian Elischer: "Re: Is ther a tool to show online throughput of a socket" 
    Date: Wed, 19 Jan 2005 11:45:26 +0300
To: Julian Elischer <julian@elischer.org>

    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. 

    -- 
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 "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Julian Elischer: "Re: Is ther a tool to show online throughput of a socket"

    Relevant Pages

    • Re: small tun(4) improvement
      ... >>however with locking.. ... >DIVERT sockets in themselfes do not depend on ipfw. ... >packets just fine through a diver socket even when ipfw is missing. ... I guess we would have done divert differently if we had done netgraph ...
      (freebsd-net)
    • RE: ng_netflow: testers are welcome
      ... like MRTG ... that this would require divert implemented as netgraph ... I have no idea how this would work with ipfw ruleset... ...
      (freebsd-isp)
    • RE: ng_netflow: testers are welcome
      ... like MRTG ... that this would require divert implemented as netgraph ... I have no idea how this would work with ipfw ruleset... ...
      (freebsd-net)
    • Re: Question about bridging code
      ... it looks like netgraph can do what I need to do. ... I guess once I moved away from the IP layer to the link layer, divert sockets ... >> bridge instead, and the transformation is to be performed on the bridged ...
      (freebsd-net)
    • Re: 5.4 -- bridging, ipfw, dot1q
      ... > I'd personally just be happy if ipfw was smart enough to know that if I ... > handle the demuxing automagically. ... As for demultiplexing, well, you COULD pass it out to a netgraph ... a direct interface between ipfw and netgraph. ...
      (freebsd-hackers)