--- On Fri, 11/12/10, Patrick McHardy <kaber@xxxxxxxxx> wrote:
> From: Patrick McHardy <kaber@xxxxxxxxx>
> Subject: Re: NFQUEUE verdicts - adding non-termination
> To: "Andrew Watts" <akwatts@xxxxxxxxx>
> Cc: netfilter-devel@xxxxxxxxxxxxxxx
> Date: Friday, November 12, 2010, 11:19 AM
> On 12.11.2010 12:11, Patrick McHardy
> wrote:
> > Am 12.11.2010 12:01, schrieb Andrew Watts:
> >> --- On Thu, 11/11/10, Patrick McHardy <kaber@xxxxxxxxx>
> wrote:
> >>
> >>> On 11.11.2010 10:01, Andrew Watts wrote:
> >>>> Hi.
> >>>>
> >>>> The NF_CONTINUE verdict that Darryl Miles
> brings up in his 11/4
> >>>> post is very interesting. NF_CONTINUE
> would provide the NFQUEUE
> >>>> target the added flexibility of, say,
> partial handling in
> >>>> userspace. A queue-handler could have a
> set of criteria that,
> >>>> when satisfied, would result in an
> immediate drop or accept. One
> >>>> could then leave the rest of the packets
> to find their fate in the
> >>>> chains/rules left to traverse. I would be
> interested in helping
> >>>> to add this verdict if someone will take
> the lead (assuming a patch
> >>>> hasn't already been written - has it?).
> >>
> >>> There's no difference between returning
> NF_ACCEPT or a new NF_CONTINUE.
> >>> Queueing happens outside of the ruleset
> context, so in either case the
> >>> packet would continue through the network
> stack directly, not after
> >>> the NFQUEUE rule.
> >>
> >> I see. Is there a way to achieve this result under
> the current
> >> infrastructure?
> >
> > Having the packet continue after the NFQUEUE rule? No,
> once the packet
> > is reinjected, that rule might not even be there
> anymore.
>
> Actually, what you can do is use NF_REPEAT as verdict and
> have the
> packet continue at the next rule based on marks. Something
> like this:
>
> Chain INPUT:
> -m mark --mark 0 -j NOT_QUEUED
> -m mark --mark 1 -j BACK_FROM_QUEUE
>
> Chain NOT_QUEUED:
> ... rules ...
> -j NFQUEUE
>
> [ nfqueue: return NF_REPEAT, set mark = 1 ]
>
> Chain BACK_FROM_QUEUE:
> ... further rules ...
>
Yes, that works quite well. If the fork is placed near the
start of the chain, you reduce the amount of redundant
traversing since it seems it goes back to square one.
I initially misunderstood the NF_REPEAT verdict after
looking at the libnetfilter_queue source "NF_REPEAT
iterate the same cycle once more".
~ Andy
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
