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

[Patrick McHardy <kaber@trash.net>]

On 05.11.2010 01:08, Pablo Neira Ayuso wrote:
> On 04/11/10 05:37, Patrick McHardy wrote:
>> 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.
> 
> We can add two new netlink attributes like:
> 
> * NFQA_CFG_NO_LISTENER_VERDICT
> * NFQA_CFG_OVERFLOW_VERDICT
> 
> These can be used to send messages from user-space to configure the
> instance, these will remain per-process parameters. It's similar to what
> we do with NFQA_CFG_QUEUE_MAXLEN.

Well, no listener can't be configured in nfnetlink_queue since the
instance goes away with the listener :) That's why I was saying that
this information needs to be included in the NF_QUEUE verdict.