[TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and
netgraph(4)
Julian Elischer
julian at elischer.org
Tue Jan 25 11:38:11 PST 2005
Gleb Smirnoff wrote:
>On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
>A> Style-wise there is only the space after "(void )..." in ip_fw_pfil.c
>A> for the ng_tee case which is too much.
>
>Ok.
>
>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?
>
I don't think that errors should be "sometimes".
we all expect udp to silently discard packets..
and queued data can not return status..
If you want to return the fact that a queue is full somewhere,
then we have messages for that.
>
>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 have no comment
>
>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().
>
>
>
More information about the freebsd-net
mailing list