Re: nft ct original oddity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 19, 2019 at 07:10:10AM +0200, Florian Westphal wrote:
> Simon Kirby <sim@xxxxxxxxxx> wrote:
> 
> [ moving to nf-devel ]
> 
> > I accidentally wrote "ct original" instead of "ct direction original",
> > and this broke "nft list ruleset":
> > 
> > # nft add set filter myset '{ type ipv4_addr; }'
> > # nft insert rule filter input ct original ip daddr @myset
> > # nft list ruleset
> > nft: netlink_delinearize.c:124: netlink_parse_concat_expr: Assertion `consumed > 0' failed.
> > Abort
> 
> Indeed.
> 
> This will fix the immediate problem:
> 
> diff --git a/src/netlink_delinearize.c b/src/netlink_delinearize.c
> --- a/src/netlink_delinearize.c
> +++ b/src/netlink_delinearize.c
> @@ -329,7 +329,7 @@ static void netlink_parse_lookup(struct netlink_parse_ctx *ctx,
>                 return netlink_error(ctx, loc,
>                                      "Lookup expression has no left hand side");
>  
> -       if (left->len < set->key->len) {
> +       if (left->len && left->len < set->key->len) {
>                 expr_free(left);
>                 left = netlink_parse_concat_expr(ctx, loc, sreg, set->key->len);
>                 if (left == NULL)
> 
> Pablo, the problem is that ct->key is NFT_CT_SRC, so expr->len is 0, so
> we try to parse a concat expression.  Its not until the evaluation step
> before we will figure out from context that SRC is asking for an ipv4
> address and update the type and expression length.
> 
> AFAICS the plan was to stop using NFT_CT_SRC and use NFT_CT_SRC_IP(6)
> instead so we have type and length info available directly.
> 
> Was there a problem with it (inet family)?

Right. In general, we need keys with fixed lengths, the NFT_CT_SRC
approach where key is variable length is a problem for the set
infrastructure, as you're describing.

There's a fix for this here:

https://patchwork.ozlabs.org/patch/883575/

It requires kernel >= 4.17.

I wanted to have netlink descriptions to deal with this case, but so
far only probing is possible, and I would like not to open up for that
path.

I can just rebase, resubmit and merge it if you are fine with it.

Thanks.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux