--- On Mon, 11/15/10, Patrick McHardy <kaber@xxxxxxxxx> wrote:
> From: Patrick McHardy <kaber@xxxxxxxxx>
> Subject: Re: NFQUEUE verdicts - adding non-termination
> To: "Stig Thormodsrud" <stig@xxxxxxxxxx>
> Cc: "Andrew Watts" <akwatts@xxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxx
> Date: Monday, November 15, 2010, 10:34 AM
> On 12.11.2010 20:54, Stig Thormodsrud
> wrote:
> > On 11/11/2010 02:50 AM, Patrick McHardy 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've been interested in this thread since I recently
> converted our
> > version of snort inline to use NFQUEUE instead of
> QUEUE. One of driving
> > factors was that I needed to have multiple QUEUE
> targets. While I was
> > doing the work I was hoping there was a verdict like
> NF_RETURN, so that
> > if it passed the snort inspection then I could have
> another NFQUEUE
> > target that would do https domain filtering.
> From reading this thread I
> > now understand why I can just continue, but I
> wondering what is that the
> > recommended approach for this type of use case?
> As it is now, I think I
> > would need to have the 2nd NFQUEUE target on a
> different hook.
>
> Look at my second response to Andrew, you can use NF_REPEAT
> and some
> mark based jumps to do this. You can also return NF_QUEUE
> from userspace
> directly and encode the queue number in the upper 16 bits.
>
Patrick, many thanks for the guidance on this. Your
advice was right on.
Stig, something to consider in addition to Patrick's
comment is that you can make the mark-based decision
more complex than just binary. Then a single queue
handler can process according to different mark values
and increment the mark on each return (until a
termination value is reached).
~ 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
