Hi,
On Fri, Apr 03, 2020 at 02:54:53AM +0200, Stefano Brivio wrote:
> Hi,
>
> On Thu, 2 Apr 2020 23:49:41 +0200
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
>
> > This patch adds a lazy check to validate that the first element is not a
> > concatenation. The segtree code does not support for concatenations,
> > bail out with EOPNOTSUPP.
> >
> > # nft add element x y { 10.0.0.0/8 . 192.168.1.3-192.168.1.9 . 1024-65535 }
> > Error: Could not process rule: Operation not supported
> > add element x y { 10.0.0.0/8 . 192.168.1.3-192.168.1.9 . 1024-65535 }
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Otherwise, the segtree code barfs with:
> >
> > BUG: invalid range expression type concat
> >
> > Reported-by: Florian Westphal <fw@xxxxxxxxx>
> > Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
>
> I know you both reported this to me, sorry, I still have to polish up
> the actual fix before posting it. I'm not very familiar with this code
> yet, and it's taking ages.
>
> It might be a few more days before I get to it, so I guess this patch
> might make sense for the moment being.
I think this one might not be worth to look further. This only happens
with old kernel and new nft binary.
After adding the set, for instance:
table x {
set y {
type ipv4_addr . ipv4_addr
flags interval
}
}
Old kernels accept this because the kernel has no concept of
concatenation, it's just a number of bytes. Then, the flag interval
selects the rbtree in the kernel.
Then, when listing back the set to userspace, the old kernel reports
no concatenation description, so nft userspace enters the segtree path
to deal with this concatenation.
I think the check in this patch is fine to report users that this
kernel is old and that adding interval concatenation is not supported
by this kernel.
Not related to this patch, Phil reported this one is still broken:
ip daddr . tcp dport { 10.0.0.0/8 . 10-23, 192.168.1.1-192.168.3.8 . 80-443 } accept
Thanks.
