Date: Tue, 25 Jan 2005 11:37:33 +0300 From: Gleb Smirnoff <glebius@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: net@freebsd.org Subject: Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and netgraph(4) Message-ID: <20050125083733.GA57770@cell.sick.ru> In-Reply-To: <41F6037E.3C7F6364@freebsd.org> References: <20050124100717.GA47663@cell.sick.ru> <41F5FED1.B6EFD246@freebsd.org> <20050125082136.GC57248@cell.sick.ru> <41F6037E.3C7F6364@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050125083733.GA57770>