path: root/doc
diff options
authorFlorian Westphal <>2019-07-13 19:23:27 +0200
committerFlorian Westphal <>2019-07-15 12:28:57 +0200
commita43a696443a150f448d182fe708a43d7279de715 (patch)
tree2e6bb18b51cea409aa963f239946cc66ab7cd4d7 /doc
parent87c0bee7f04917623c35e850ad223222a93520d1 (diff)
proto: add pseudo th protocol to match d/sport in generic way
Problem: Its not possible to easily match both udp and tcp in a single rule. ... input ip protocol { tcp,udp } dport 53 will not work, as bison expects "tcp dport" or "sctp dport", or any other transport protocol name. Its possible to match the sport and dport via raw payload expressions, e.g.: ... input ip protocol { tcp,udp } @th,16,16 53 but its not very readable. Furthermore, its not possible to use this for set definitions: table inet filter { set myset { type ipv4_addr . inet_proto . inet_service } chain forward { type filter hook forward priority filter; policy accept; ip daddr . ip protocol . @th,0,16 @myset } } # nft -f test test:7:26-35: Error: can not use variable sized data types (integer) in concat expressions During the netfilter workshop Pablo suggested to add an alias to do raw sport/dport matching more readable, and make it use the inet_service type automatically. So, this change makes @th,0,16 work for the set definition case by setting the data type to inet_service. A new "th s|dport" syntax is provided as readable alternative: ip protocol { tcp, udp } th dport 53 As "th" is an alias for the raw expression, no dependency is generated -- its the users responsibility to add a suitable test to select the l4 header types that should be matched. Suggested-by: Pablo Neira Ayuso <> Signed-off-by: Florian Westphal <> Acked-by: Pablo Neira Ayuso <>
Diffstat (limited to 'doc')
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/payload-expression.txt b/doc/payload-expression.txt
index b98a6077..dba42fd5 100644
--- a/doc/payload-expression.txt
+++ b/doc/payload-expression.txt
@@ -498,6 +498,15 @@ Transport Header, for example TCP
inet filter input meta l4proto {tcp, udp} @th,16,16 { 53, 80 }
+The above can also be written as
+inet filter input meta l4proto {tcp, udp} th dport { 53, 80 }
+it is more convenient, but like the raw expression notation no
+dependencies are created or checked. It is the users responsibility
+to restrict matching to those header types that have a notion of ports.
+Otherwise, rules using raw expressions will errnously match unrelated
+packets, e.g. mis-interpreting ESP packets SPI field as a port.
.Rewrite arp packet target hardware address if target protocol address matches a given address