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

[Gleb Smirnoff]

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

ENOMEM and ESRCH can be returned by ng_ipfw_input() itself. EACCES can be returned
by ipfw_check_{in,out}. All other errors can be returned indirectly by other
nodes, via NG_SEND_DATA_ONLY() macro. These errors are out of our control.
Do you want this construction at end of ng_ipfw_input()?

	NG_SEND_DATA_ONLY(error, hook, m);

	if (error == EACCES ||
	    error == ENOMEM ||
	    error == ESRCH)
		return (error);
	else
		return (0);

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

Yes. I thought it is better to allocate tag only after a sending hook was found.
I will accept after I hear more opinions.

A> > A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
A> > A> to unwind the stack?
A> > 
A> > No. The stack will be unwinded when packet travels thru netgraph and returned
A> > back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
A> > is configured in ng_ipfw_connect().
A> 
A> What if the packet doesn't make its way back to ng_ipfw?  I can imagine a
A> lot of configurations where this may happen (intential).  The problem comes
A> back again and is much less obvious if the stack breaks.

If the packet does not come back to ng_ipfw, then we do not have any recursion
and stack problems.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE