netfilter buglog - Jul 2019 - [Bug 1356] New: adding element to map inverts byte order

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

            Bug ID: 1356
           Summary: adding element to map inverts byte order
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: c.marquis at viapass.com

Hi, i noticed a byte order inversion while adding an element to a verdict map,
as following:
> nft add element ip filter ok { 0x00000045: jump go }

produces:
> map ok {
>     type mark : verdict
>     elements = { 0x45000000 : jump go }
> }

(version: both nftables and libnftnl from last commit on this day 24 July 2019
- 11h40 AM)

-- 
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/20190724/abf093f6/attachment.html>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #1 from Pablo Neira Ayuso <pablo at netfilter.org> ---
# cat /tmp/x.nft 
table x {
        chain go {
        }

        map ok {
            type mark : verdict
        }
}

# nft add element ip x ok { 0x00000045: jump go }

# nft list ruleset
table ip x {
        map ok {
                type mark : verdict
                elements = { 0x00000045 : jump go }
        }

        chain go {
        }
}

This works fine here, you're on x86_64 as your hardware field in this bug
report specifies?

-- 
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/20190724/9dbbe442/attachment.html>

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

--- Comment #2 from c.marquis at viapass.com ---
> uname -a
Linux lab-gw 4.4.0-154-generic #181-Ubuntu SMP Tue Jun 25 05:29:03 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux

yes, a fresh Ubuntu 16.04 LTS on a VM (ESXi)

-- 
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/20190724/413fd5cb/attachment.html>

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

--- Comment #3 from c.marquis at viapass.com ---
another information : the mark matching is done correctly, meaning i look for
mark 0x00000040, it will match this mark and jump, only the export (nft list
ruleset) shows 0x40000000
if this can help

-- 
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/20190724/c60bda5e/attachment.html>

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

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Probably this rule was generated via libnftnl?

-- 
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/20200721/8189cd4d/attachment.html>