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. stig -- 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
