netfilter buglog - Jan 2014 - [Bug 888] New: Assertion errors attempting a statement which (I believe) is grammatically correct.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

           Summary: Assertion errors attempting a statement which (I
                    believe) is grammatically correct.
           Product: nftables
           Version: unspecified
          Platform: x86_64
        OS/Version: Fedora
            Status: NEW
          Severity: normal
          Priority: P5
         Component: nft
        AssignedTo: pablo at netfilter.org
        ReportedBy: deleriux1 at gmail.com
   Estimated Hours: 0.0


The following expression does not work on the set. From what I've seen from
the
bison grammer file this appears to be valid syntax.. this rule works using a
singleton, but declaring it an anonymous set does not.


<some basic table initialization..>
nft> add rule ip filter input ip saddr != { 192.168.1.0/24 } reject
BUG: invalid expression type set
nft: src/evaluate.c:955: expr_evaluate_relational: Assertion `0' failed.
Aborted


Additionally the following also fails; From looking at the source there does
not appear to be a set type declared for network blocks and seeing that this
works when declared inline as an anonymous set I imagine this behaviour is not
desirable.

<some basic table initialization..>
nft> add map filter admin_addresses { type ipv4_address; }
nft> add element filter admin_addresses { 192.168.1.0/24 }
nft: src/netlink.c:155: alloc_nft_setelem: Assertion `expr->ops->type
=EXPR_MAPPING' failed.
Aborted

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

Yuxuan Shui <yshuiv7 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yshuiv7 at gmail.com

--- Comment #1 from Yuxuan Shui <yshuiv7 at gmail.com> 2014-03-13 14:49:41
CET ---
I believe nftables doesn't support binary ops against a set.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

--- Comment #2 from Yuxuan Shui <yshuiv7 at gmail.com> 2014-03-13 16:29:27
CET ---
Hmm, as my understanding of the nftables code goes, I think the set lookup
operation doesn't support prefix either.

I'll write a small patch to let nft fail gracefully as a warmup for GSoC :)

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

--- Comment #3 from Yuxuan Shui <yshuiv7 at gmail.com> 2014-03-13 17:55:09
CET ---
Created attachment 438
  --> https://bugzilla.netfilter.org/attachment.cgi?id=438
A tiny patch that adds one line of debug output.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |kaber at trash.net

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> 2014-06-05
17:37:07 CEST ---
Including Patrick in this bug, in case he's got some better idea to address
this.

Currently, we can only use the implement 'eq', ie.

  ip saddr { 1.1.1.0/24 }

But we should be able to support this:

  nft add rule ip filter input ip saddr != { 192.168.1.0/24 }

it says:

  BUG: invalid expression type set
  nft: src/evaluate.c:955: expr_evaluate_relational: Assertion `0' failed.
  Aborted

My proposal is to add a NFT_LOOKUP_NEG whose attribute type is NLA_FLAG when
validating in nft_lookup.c to support "negative" lookups. The
corresponding
libnftnl and nftables are required as well.

Please, Shui let us know how this is going.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

--- Comment #5 from Yuxuan Shui <yshuiv7 at gmail.com> 2014-06-05 21:05:11
CEST ---
(In reply to comment #4)
> Including Patrick in this bug, in case he's got some better idea to
address
> this.
> 
> Currently, we can only use the implement 'eq', ie.
> 
>   ip saddr { 1.1.1.0/24 }
This is not actually an OP_EQ, it's an OP_IMPLICIT which later tranlated to
OP_LOOKUP. Currently there's no way to explicitly specify OP_LOOKUP.
> 
> But we should be able to support this:
> 
>   nft add rule ip filter input ip saddr != { 192.168.1.0/24 }
It seems there're no negative lookup implementation in nft now. If we are
going
to support this we have to implement a negative lookup operation.

Also I think '!=' is not a good operator for this, what about
"notin" (also use
"in" for OP_LOOKUP)?
> 
> it says:
> 
>   BUG: invalid expression type set
>   nft: src/evaluate.c:955: expr_evaluate_relational: Assertion `0'
failed.
>   Aborted
> 
> My proposal is to add a NFT_LOOKUP_NEG whose attribute type is NLA_FLAG
when
> validating in nft_lookup.c to support "negative" lookups. The
corresponding
> libnftnl and nftables are required as well.
(Well I didn't read this part when typing above paragraphs). I think I could
do
this.
> 
> Please, Shui let us know how this is going.
-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

--- Comment #6 from Yuxuan Shui <yshuiv7 at gmail.com> 2014-06-05 21:20:15
CEST ---
Well I'll add a OP_LOOKUP_NEG, which linearize to "lookup_neg"
when sending to
kernel. And reuse the nft_lookup_eval function, but reverse the logic. 

i.e. change

    if (set->ops->lookup(set, &data[priv->sreg],
&data[priv->dreg]))
        return;
    data[NFT_REG_VERDICT].verdict = NFT_BREAK;

to

    if (set->ops->lookup(set, &data[priv->sreg],
&data[priv->dreg]))
        data[NFT_REG_VERDICT].verdict = NFT_BREAK;

How does this sound?

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=888

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #7 from Pablo Neira Ayuso <pablo at netfilter.org> 2014-06-25
19:40:26 CEST ---


*** This bug has been marked as a duplicate of bug 923 ***

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.