netfilter: nfqueue: add ability to dump list of supported attributes

Allows userspace to dump the list of known (extended) attributes. For SKB_INFO, we set all the info flag bits supported by the running kernel.

The latter is required because absence of some bits in the info attribute will either mean "skb did not have the property" OR "this kernel doesn't know about this flag".

---
Recent discussion of the
"netfilter: nf_queue: add NFQA_SKB_CSUM_NOTVERIFIED info flag" patch
(http://patchwork.ozlabs.org/patch/246460/) shows that we'll need to tell userspace the supported info bits in the NFAQ_SKB_INFO attribute.

While we could add another NFAQ_SKB_INFO_FLAGS attribute, that seems insane since the value will never change (unless kernel update).

Adding feature flags also seems to be wrong (API abuse, plus we'd waste a new feature flag for every new SKB_INFO bit).

On startup, userspace would bind the queue, and then send NFQNL_MSG_ATTRIBUTES request to kernel.

In the reply, the known extended attrs will be set, i.e:

if (attr[NFQA_SKB_INFO]) {
uint32_t skbinfo = ntohl(mnl_attr_get_u32(attr[NFQA_SKB_INFO])); if (skbinfo & NFQA_SKB_CSUMNOTVERIFIED) /* kernel support checksum hints */

After this, userspace can process queued packets and interpret absence of flags correctly.

index a2308ae..efb02ae 100644
@@ -9,6 +9,7 @@ enum nfqnl_msg_types {
 	NFQNL_MSG_VERDICT,		/* verdict from userspace to kernel */
 	NFQNL_MSG_CONFIG,		/* connect to a particular queue */
 	NFQNL_MSG_VERDICT_BATCH,	/* batchv from userspace to kernel */
+	NFQNL_MSG_ATTRIBUTES,		/* list of supported attributes */
 
 	NFQNL_MSG_MAX
 };

1.7.8.6

Hi Florian,

After going back to this issue, I think I prefer to enqueue:

netfilter: nf_queue: add NFQA_SKB_CSUM_NOTVERIFIED info flag

to net-next, and ask for -stable submission once this hits net, as it will be fixing an inconsistent behaviour. Another reason for that is that such patch is fairly small (~16 LOC).

Both approaches we discussed that are:

a) adding a new config flags

and

b) adding this infrastructure

look a bit too much to me just to resolve this.

Once this patch hits -stable, we can consistently say that:

NFQA_SKB_CSUMNOTREADY
NFQA_SKB_GSO
NFQA_SKB_CSUM_NOTVERIFIED

are obtained via NFQA_CFG_F_GSO.

For user-space application running with different, they can still send every configuration incrementally, so you spot a message telling what is available and what is not. I planned to use this to add GSO support for the user-space helper infrastructure.

Let me know.

I have no objections.

However, we cannot escape this forever -- it will be insanity to just ask for -stable submission whenever a new flag is added and expect noone to yell at us :-)

But for the time being, sure, b) _is_ overkill.