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

[Andre Oppermann]

Gleb Smirnoff wrote:
> 
> On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
> A> I don't like the arbitrary back-passing of errors from ng_ipfw.  I'm
> A> fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
> A> else.  Getting back any other error is very confusing and non-intuitive
> A> when looking at the error of an application having packets sunk there.
> 
> So you want "return (0)" at end of ng_ipfw_input()? My vote is against.
> Julian, Brooks?

No, I want only get EACCES, ENOMEM or ESRCH back and nothing else.
I didn't I want only "return (0)".

> A> Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
> A> doing it?  Dummynet should do the same to get it consistent again.
> 
> Not sure that this is good. These tags are foreign to ipfw, they belong
> to other facilities.

I guess ng_ipfw is pretty much specific to ipfw, no?

> A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
> A> to unwind the stack?
> 
> No. The stack will be unwinded when packet travels thru netgraph and returned
> back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
> is configured in ng_ipfw_connect().

What if the packet doesn't make its way back to ng_ipfw?  I can imagine a
lot of configurations where this may happen (intential).  The problem comes
back again and is much less obvious if the stack breaks.

I'm out now until tomorrow afternoon.

-- 
Andre