bugzilla-daemon at netfilter.org
2017-Feb-28 21:15 UTC
[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>
bugzilla-daemon at netfilter.org
2017-Mar-18 11:55 UTC
[Bug 1125] Setting bit mark according to result of lookup
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>
bugzilla-daemon at netfilter.org
2017-Mar-29 21:51 UTC
[Bug 1125] Setting bit mark according to result of lookup
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>
Reasonably Related Threads
- [Bug 1057] New: Allow for multiple protocols to be specified in a rule
- as.Date(Inf) displays as 'NA' but is actually 'Inf'
- as.Date(Inf) displays as 'NA' but is actually 'Inf'
- as.Date(Inf) displays as 'NA' but is actually 'Inf'
- [Bug 1125] packet_get_int() returns -1 (serverloop.c)