Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)
From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 01/20/05
- Previous message: Brooks Davis: "Re: [PATCH] 802.1p priority (fixed)"
- In reply to: Gleb Smirnoff: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)"
- Next in thread: Andre Oppermann: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) andnetgraph(4)"
- Reply: Andre Oppermann: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) andnetgraph(4)"
- Reply: Julian Elischer: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 20 Jan 2005 11:34:32 -0800 To: Gleb Smirnoff <glebius@freebsd.org>
On Thu, Jan 20, 2005 at 04:45:53PM +0300, Gleb Smirnoff wrote:
> 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.
I think the code should be committed more or less as is. I think the
netgraph and divert features are relatively orthogonal.
-- Brooks
-- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
- application/pgp-signature attachment: stored
- Previous message: Brooks Davis: "Re: [PATCH] 802.1p priority (fixed)"
- In reply to: Gleb Smirnoff: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)"
- Next in thread: Andre Oppermann: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) andnetgraph(4)"
- Reply: Andre Oppermann: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) andnetgraph(4)"
- Reply: Julian Elischer: "Re: [TEST/REVIEW] ng_ipfw: node to glue together ipfw(4) and netgraph(4)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|