[Bug 1125] Setting bit mark according to result of lookup

[bugzilla-daemon at netfilter.org]

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>