All of lore.kernel.org
 help / color / mirror / Atom feed
* vmaps and default action
@ 2020-01-13 11:05 Florian Westphal
  0 siblings, 0 replies; only message in thread
From: Florian Westphal @ 2020-01-13 11:05 UTC (permalink / raw)
  To: netfilter-devel

Hi,

currently a ruleset like this loads fine:

table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
                meta l4proto vmap { tcp : jump tcp_chain, udp : jump udp_chain } counter packets 0 bytes 0 jump other_chain
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }

        chain tcp_chain {
                counter packets 18 bytes 1017
        }

        chain udp_chain {
                counter packets 0 bytes 0
        }

        chain other_chain {
                counter packets 0 bytes 0
        }
}

but it doesn't do what would be expected, tcp or udp traffic will
jump to the appropriate chain, but 'other' protocols will never
make it to other_chain.

Instead, users need a workaround like this:

table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
                jump test_proto_chain
        }

        chain test_proto_chain {
                meta l4proto vmap { tcp : goto tcp_chain, udp : goto udp_chain }
                counter packets 2 bytes 168 goto other_chain
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }

        chain tcp_chain {
                counter packets 29 bytes 1966
        }

        chain udp_chain {
                counter packets 4 bytes 774
        }

        chain other_chain {
                counter packets 2 bytes 168
        }
}

The intermediate chain (test_proto_chain) allows to then call the real chains
via goto, so the remaining rules in test_proto_chain get omitted in case the
goto label is found, and if not the next rule does the catchall/default handling.

This isn't really nice, there should be a better way to do this.

It would be possible to make ruleset A just work by resurrecting my old patch
to not set NFT_BREAK in case no vmap entry is found, then the rule would
continue evaluation and hit the '... jump other' expression.

If thats unwanted, nft should at least complain/warn that the 'counter jump other_chain'
part will never be run, i.e. similar to how nft handles constructs like this:

inet-filter:7:25-31: Error: Statement after terminal statement has no effect
jump test_proto_chain counter accept
~~~~~~~~~~~~~~~~~~~~~ ^^^^^^^

I can make a patch that adds this warning, are there any suggestions on how to handle/add
default/catchall support?

I still think making 'A' "just work" is the most sane option, it needs very little
kernel changes, needs no extra keywords and it looks "natural" to me to make vmap a no-op
if no jump/goto was executed.




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-01-13 11:05 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-13 11:05 vmaps and default action Florian Westphal

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.