cvs commit: src/sbin/ipfw ipfw2.c src/sys/netgraph ng_ipfw.cng_ipfw.h src/sys/netinet ip_fw.h ip_fw2.c ip_fw_pfil.c

[Andre Oppermann]

Gleb Smirnoff wrote:
> 
> On Thu, Feb 10, 2005 at 11:52:10AM +0100, Andre Oppermann wrote:
> A> I have not withdrawn my objections to the non-decoupling upon entering
> 
> You haven't replied my email and reminder during more than a week. On last mail
> you have said, that you are going to be online in one day.

Yes, that right.  $work and family take their time too and I'm sorry
that I didn't have much time for FreeBSD since christmas.

> A> into netgraph.  I think you should decouple the stack upon entering
> A> netgraph and not when returning back to ng_ipfw.  It is not neccessary
> A> to go back the same way and I can imagine several normal setups where
> A> packets may come back through another way leading to recursions and a
> A> very (too) deep stack.  NG_SEND_DATA_ONLY() doesn't seem to decouple
> A> it but it's hard to follow the netgraph code and I'm not too used to
> A> it.  If you can show that NG_SEND_DATA_ONLY() does in fact decouple
> A> it then I withdraw this objection.
> 
> Andre, all other edge netgraph nodes does not queue packet for ISR.
> "Edge node" stands for a node which is an interface between netgraph and
> other networking subsystem. It has been proved in practice, that it is not
> needed. And in theory, there is no way ro recurse. You say, that you can
> describe a normal setup which leads to recursion. I can't. So pls describe it.

There is a major difference to the other edge nodes.  When ng_ipfw is
being entered the pfil lock is still held we are in the middle of
ip_input/ouput() processing.  For example I can quite readily imagine
someone ng-diverting all SMTP TCP sessions into some kind tunneling
encapsulation, perhaps through ng_ppp->ng_l2tp which causes the packet
so re-enter ip_input() again.  Then it may be that I have another
ng-diversion either intentionally or accidentially causing my stack
to grow until it explodes.  In addition the pfil read lock is held
all the time and even recursed on.  Given a certain traffic level it
may load to deadlock or prevent any pfil hooks changes for a long time.
This is dangerous territory and netgraph is not bound in depth or path
a packet may take.

ng_ipfw is special in this regard compared to other netgraph edges
precisely because it gets called from the middle of ip_input/output().
And because of that you have to do some special treatment.  I wouldn't
complain if there were a guarnatee that packets going out via ng_ipfw
absolutely come back through it again, but there isn't.  You can set
it up as one-way thing.

> A> The other thing is the passing back of errors from netgraph.  Only
> A> certain kinds of errors should be reported back and others converted
> A> to some default error.  It is very confusing for an application
> A> developer to get a very (from his POV) non-sensical error message
> A> like ENOTCONN when writing on a socket.  He doesn't have knowledge
> A> of the ipfw/netgraph stuff that happens in the kernel and it makes
> A> debugging extremely confusing.  In the he blames FreeBSDs socket
> A> implementation whereas it was only some error in setting up the
> A> netgraph by the administrator.
> 
> I have already replied this in net@ list. OK, I'll ask again: Do you want
> ng_ipfw_rcvdata() to end with "return (0)"?

No.  I want it to pass EACCES, ENOMEM/ENOBUFS and everything else as
ENXIO (including if hook not connected).  In a previous email I said
ESRCH was ok, but it really doesn't make sense and is pretty confusing
to an application writer.  ENXIO is much better and not to be confused
with possible programming errors from application side.

-- 
Andre