netfilter buglog - Feb 2017 - [Bug 1125] New: Setting bit mark according to result of lookup

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

            Bug ID: 1125
           Summary: Setting bit mark according to result of lookup
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Gentoo
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: uzytkownik2 at gmail.com

I tried to set a mark according to interface it come through. My first attempt
was:

table bridge filter {
    map iface_to_mark {
        type iface_index: mark
        elements = {
            iface0: 0x1,
            iface1: 0x2,
            ...
        }
    }
    chain input {
        type filter hook input priority 0
        mark set mark or iif map @iface_to_mark
    }
}

However as RHS of | is not constant it is not allowed. I WAR by vmap jump
depending on interface and inlining constants but it is much less clearer (and
probably much less performant) then simple lookup and or.

-- 
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/20170228/fd5fa7af/attachment.html>

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

Robert White <rwhite at pobox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwhite at pobox.com

--- Comment #1 from Robert White <rwhite at pobox.com> ---
Put the value from the map into the mark first.

e.g. start the mark construction with

add rule wherever wherever meta mark set iif map @iface_to_mark

Then compose in your other stuff...

BTW: may not be relevant but I do most of my interface stuff by group id number
instead of marking the packets. So, for instance, instead of slicing on a
classifier bit I just have all my interfaces by category. external==1,
bridge==2, wired==3, and wireless==4. (interfaces start life in group 0.) These
groups are set with the ip command - typically in the interface config or
"up"
script as

"ip link set dev _ifname_ group _number_"


This is conveniently not included in the help or manual pages. /sigh

iifgroup and oifgroup are, thereafter, good for testing and searching maps and
sets and dictionaries.

Also the group numbers "exist" before any interfaces are even
configured
because, hey, integers exist. So by moving interfaces in and out of groups you
can radically change their behaviors without having to load/update any rules or
sets/maps/dictionaries

More complicated arrangements may need more groups.

DISCLAIMER: I've only played with this in nftables, but I've used
interface
groups in iptables for a little while now and it beats the heck out of playing
name globing games. I'm wating for nft version 0.8 before I really cut over
since I need intervals in sets/maps but the nft 0.7 cannot output those with
nft list ruleset so YMMV. 8-)

-- 
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/20170318/088974c4/attachment.html>

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

--- Comment #2 from Maciej Piechotka <uzytkownik2 at gmail.com> ---
(In reply to Robert White from comment #1)
> Put the value from the map into the mark first.
> 
> e.g. start the mark construction with
> 
> add rule wherever wherever meta mark set iif map @iface_to_mark
> 
> Then compose in your other stuff...
> 
This wouldn't work as the idea is that the packet gets a bitmask of
interfaces
as it goes through the bridge filter. So if we have eth0 and eth1 both under
br0 and eth0 -> b001, eth1 -> b010, br0 -> b100 then packets from eth0
would
have b101 and from eth1 b110.
> Also the group numbers "exist" before any interfaces are even
configured
> because, hey, integers exist. So by moving interfaces in and out of groups
> you can radically change their behaviors without having to load/update any
> rules or sets/maps/dictionaries
> 
> More complicated arrangements may need more groups.
> 
OTOH names are more user-readable and I don't have very high performance
requirements[1].

[1] That said in the current version there is chicken-and-egg problem between
nft and interfaces. Ideally you would want the firewall up and running before
setting the network. But to use high performance features such as iff you need
to set up it after the network as you need to create interfaces and some
interfaces might require network itself (tunnels etc.). I guess the simplest
thing would be to (re-)JIT on network creation/destruction/rename i/offname so
that the i/off is substituted for interface and compiles out for non-existing
interface.

-- 
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/20170329/2a7a82d0/attachment.html>