On 05/11/10 10:29, Patrick McHardy wrote: > 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 :) Oh, I forgot that this is a chicken-egg problem :-(. > That's why I was saying that > this information needs to be included in the NF_QUEUE verdict. Indeed, that seems to me the good choice :-). -- 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
