Re: Can NFQUEUE accept/continue when there is no userspace listener registered ?

[Patrick McHardy <kaber@trash.net>]

On 04.11.2010 04:52, Darryl Miles wrote:
> Is there any mechanism which would allow additional options to NFQUEUE
> target to instruct the kernel what to do:
> 
>  --action-no-listener NF_ACCEPT|NF_DROP|CONTINUE  (with NF_DROP being
> the default)
>  --action-backlog-overflow NF_ACCEPT|NF_DROP|CONTINUE   (with NF_DROP
> being the default)

--action-no-listener is hard to do because the rule has no direct
connection to the queue and backend queueing mechanism and thus
it can't determine whether a listener exists. There's also currently
no way to propagate that information to the backend. Well, maybe
you could encode it in the verdict, similar to the queue number.

--action-backlog-overflow should be pretty easy to add to the
queueing backend itself (nfnetlink_queue), however when the packet
reaches the backend, it has already left the ruleset, so it won't
continue in the chain but instead continue as if a verdict of
NF_ACCEPT had been issued.

> Where CONTINUE would in effect ignore the existence of the "-j NFQUEUE"
> rule in the chain and continue to the next rule.  I guess this is
> possible if the packet never made it to user-space.
> 
> 
> Would there be any objections to providing a patch to kernel and
> userspace tooling to provide this configurable behavior ?   Is it
> obviously useful to others ?

Having the packet continue when the queue overflows has been requested
a couple of times for hung snort processes, so yes, this sounds useful.
If you can implement the no-listener feature in a reasonable way that
also sounds useful.