netfilter buglog - Mar 2024 - [Bug 1739] New: meta mark 0x80000000 display error

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

            Bug ID: 1739
           Summary: meta mark 0x80000000 display error
           Product: nftables
           Version: 1.0.x
          Hardware: All
                OS: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: k at vodka.home.kg

nft add chain test chai
nft delete table test
nft create table test
nft add chain test test
nft add rule test test meta mark and 0x40000000 != 0
nft add rule test test meta mark and 0x80000000 != 0
nft list table test
table ip test {
        chain test {
                meta mark & 0x40000000 != 0x00000000
                meta mark != 0x00000000/1
        }
}

somewhere mark treated as signed 32bit value ?

nftables v1.0.9 (Old Doc Yak #3)

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240301/50be8cd1/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at nwl.cc

--- Comment #1 from Phil Sutter <phil at nwl.cc> ---
It is merely a display issue at least:

# nft --debug=netlink add rule t c 'meta mark and 0x80000000 != 0'
ip t c
  [ meta load mark => reg 1 ]
  [ bitwise reg 1 = ( reg 1 & 0x80000000 ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]

# nft --debug=netlink list chain t c
ip t c 2
  [ meta load mark => reg 1 ]
  [ bitwise reg 1 = ( reg 1 & 0x80000000 ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]

table ip t {
    chain c {
        meta mark != 0x00000000/1
    }
}

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240301/6e1c8483/attachment.html>

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

--- Comment #2 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Phil Sutter from comment #1)
> It is merely a display issue at least:
> 
> # nft --debug=netlink add rule t c 'meta mark and 0x80000000 != 0'
> 
> ip t c
>   [ meta load mark => reg 1 ]
>   [ bitwise reg 1 = ( reg 1 & 0x80000000 ) ^ 0x00000000 ]
>   [ cmp neq reg 1 0x00000000 ]
> 
> # nft --debug=netlink list chain t c
> ip t c 2
>   [ meta load mark => reg 1 ]
>   [ bitwise reg 1 = ( reg 1 & 0x80000000 ) ^ 0x00000000 ]
>   [ cmp neq reg 1 0x00000000 ]
> 
> table ip t {
> 	chain c {
> 		meta mark != 0x00000000/1
> 	}
> }
It is possible to disable prefix notation in meta mark if it is difficult to
understand.

0x80000000 is translated into a prefix which is /1

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240319/cd824202/attachment.html>

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

--- Comment #3 from bolvan <k at vodka.home.kg> ---
Why only 0x80000000 trigger this behavior ?
What has prefix notation has to do with the mark ?

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240319/42cd8118/attachment.html>

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

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to bolvan from comment #3)
> Why only 0x80000000 trigger this behavior ?
> What has prefix notation has to do with the mark ?
not only 0x80000000, but also:

table ip x {
        chain y {
                type filter hook output priority 0;
                meta mark and 0xc0000000 != 0
                meta mark and 0xe0000000 != 0
                meta mark and 0xf0000000 != 0
        }
}

results in:

table ip x {
        chain y {
                type filter hook output priority filter; policy accept;
                meta mark != 0x00000000/2
                meta mark != 0x00000000/3
                meta mark != 0x00000000/4
        }
}

because:

0x80000000
0xc0000000
0xe0000000
0xf0000000
...

and so on.

Those are interpreted as a prefix. If this behaviour is confusing, it only
takes a oneliner to remove this behaviour...

diff --git a/src/datatype.c b/src/datatype.c
index 3205b214197f..b368ea9125fc 100644
--- a/src/datatype.c
+++ b/src/datatype.c
@@ -1015,7 +1015,6 @@ const struct datatype mark_type = {
        .print          = mark_type_print,
        .json           = mark_type_json,
        .parse          = mark_type_parse,
-       .flags          = DTYPE_F_PREFIX,
 };

 static const struct symbol_table icmp_code_tbl = {

... if it is judged to be counterintuitive.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240319/aea80343/attachment.html>

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

--- Comment #5 from bolvan <k at vodka.home.kg> ---
I think it's reasonable to distinguish data types.
Mark is just an uint32_t. It has no relation to network masks and CIDR
notation.
Taking any int/uint out of context and showing it depending on their value in
different forms - is it useful ? I don't think so

Personally when I saw this 0x00000000/1, I had no idea what it is. And had no
idea what makes 0x80000000 more special than 0x40000000. I thought the problem
was in incorrect sign tracking

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240321/6684fec1/attachment.html>

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

--- Comment #6 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to bolvan from comment #5)
> I think it's reasonable to distinguish data types.
> Mark is just an uint32_t. It has no relation to network masks and CIDR
> notation.
> Taking any int/uint out of context and showing it depending on their value
> in different forms - is it useful ? I don't think so
> 
> Personally when I saw this 0x00000000/1, I had no idea what it is. And had
> no idea what makes 0x80000000 more special than 0x40000000. I thought the
> problem was in incorrect sign tracking
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20240321122401.310768-1-pablo
at netfilter.org/

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240321/9e120c7b/attachment.html>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240604/1d14fd2e/attachment.html>