Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Mon, Jan 25, 2016 at 11:15:44AM +0000, Asbjørn Sloth Tønnesen wrote: > > This option was already silently allowed by 991fc4ae, > > but didn't have any effect. > > > > This patch adds the check and documents it. > > Applied, thanks. > > > Cc: Clemence Faure <clemence.faure@xxxxxxxxxx> > > Signed-off-by: Asbjørn Sloth Tønnesen <ast@xxxxxxxxxx> > > --- > > > > Notes: > > I tried to create a test case, as well but I didn't > > seam to be able to get --label-add to work with > > create. It only works if a -m connlabel rule exists on the system at the moment. https://patchwork.ozlabs.org/patch/553363/ extends it to nftables. > Cc'ing Florian. I think it would be good to have a test for this label > support for conntrack. Right. We could just add nf_connlabels_get(ctx->net, (len * BITS_PER_BYTE) - 1); When attempting to add a label via ctnetlink and label support isn't active. However, unlike the nft/xtables path this would be one-way: When you have a ruleset that uses -m connlabel, then flush/delete the ruleset the extension will not be added to new conntracks anymore since ->destroy() hook invocation will _put the connlabel extension usage count. For ctnetlink there is no such thing unfortunately (unless we'd add refcnts to the individual conntracks but thats something I don't want to do since it seems ridiculously expensive with no real gain). -- 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
