netfilter buglog - May 2018 - [Bug 1253] New: interface wildcard in variables causes Error: Byteorder mismatch: expected big endian, got host endian

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

            Bug ID: 1253
           Summary: interface wildcard in variables causes Error:
                    Byteorder mismatch: expected big endian, got host
                    endian
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: ian.kumlien at gmail.com

if you do:
define $interfaces = {
  tun*,
  lo
}

and then using that variable:
iifname $interfaces accept

results in:
Error: Byteorder mismatch: expected big endian, got host endian

but if i do:
iifname tun* accept

it works.

This, is odd, and should be fixed ;)

nft 0.8.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/20180501/98c7161d/attachment.html>

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

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
(In reply to Ian Kumlien from comment #0)
> if you do:
> define $interfaces = {
>   tun*,
>   lo
> }
> 
> and then using that variable:
> iifname $interfaces accept
> 
> results in:
> Error: Byteorder mismatch: expected big endian, got host endian
Yes, problem is that
iifname { "tun*", "lo" }

cotains a "*".
> but if i do:
> iifname tun* accept
> 
> it works.
Yes, in this case we just do "iifname tun", with the difference that
we compare
3 bytes instead of 4 (with a \0 character).

For the lookup case, we can't do it, as no cmp happens, we instead pass
the interface name as key to the set lookup function, i.e. the "*"
will never
match, as we can't know that we only should lookup "tun", not e.g.
"tun0" or
"veth1".

So, its likely we need to present a better error message rather than this
obscure followup error.

-- 
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/20190712/19481a4e/attachment.html>

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

--- Comment #2 from Ian Kumlien <ian.kumlien at gmail.com> ---
But that also causes a inconsistency that is not expected, ie it's expected
that the iifname <var> would be the same as iifname { <var>,
<other> }

If iifname { ... } is different this will lead to all kinds of errors.

you'd think that iifname { <x>, <y> } would result in iifname
<x> ; iifname <y>

-- 
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/20190712/0dc73718/attachment-0001.html>