From patchwork Wed Aug 1 17:28:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TcOhdMOpIEVja2w=?= X-Patchwork-Id: 952312 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ijZ9ZoC5"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41ggK16my3z9sCX for ; Thu, 2 Aug 2018 03:29:09 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407536AbeHATPv (ORCPT ); Wed, 1 Aug 2018 15:15:51 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:46267 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407064AbeHATPu (ORCPT ); Wed, 1 Aug 2018 15:15:50 -0400 Received: by mail-wr1-f68.google.com with SMTP id h14-v6so20900526wrw.13 for ; Wed, 01 Aug 2018 10:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=qw5G4lNlIZKXSuTcaQfUO0YBF5MrSi5zJPcKjBTBZhc=; b=ijZ9ZoC5c/AeswLDqdAujkFCXOmYyLbE22Y4jiM04JEy+M9xF2YsaUwzjIAI6ZG9Ve bFeu/LHjfdurQd+/hy2y+G/xlZ4OSczsp4wh8hZ2W+pOKYw3k5+WddK4W/qedYysQrmd uebL7uhTXS4CW1Lr/2UmCQtAifgWJZRZH+xH5c6p7goBgGIs/+RDgKVAia1oX+F8S4Yn MFdgXEBsDe0+DK66IkSOwhtScoNgRx+6CyGW7lRrkPR9ORcWiS33o2KzuxuoRj9EcMvT qUR+BMH8geV2batzIvTQFpxOYvXEFYkHystH7+UIha21iSbIXWusevTepN7RkYfw8Yly TsRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=qw5G4lNlIZKXSuTcaQfUO0YBF5MrSi5zJPcKjBTBZhc=; b=fTV3aDLKcGoEZz8whPBHGDy20Iz8mqwr8pUUIcBsC/aXl+PXeDNPoYn7HQYe20S3rQ sQIbVLjxy7Tjyx8B/Oeb+ZksDsmN1in8fuD3mCA0BTo0O+o8Kl+a7D93NjmYcoHXWVRT ynieei438+8f5evm+AZ/p7krYZjDB5v3UcxYDQ5UMD2hmYwUPnnRWhOOYftbNU8y2PPp XhekyH2U01LmbZScuLxlt1zn0VLdzafTMJ0/Wo1lmz3C3jNEvu7jONpGju0NiLUayNyf 8i/De3sDuLFif5DtRTOeLiVjTJ76jg1cWB7MxAzY5Nv7n8gI7rsLdfTzZnOao5LZHkXS 5QyA== X-Gm-Message-State: AOUpUlGIPpF+xH1iAwa6y4ft4XA2vpkJJyaAoxK1at/Vj6gdOW1a8yeL kWVr+jfFlr8yW99HZTLwoXpr7dDy X-Google-Smtp-Source: AAOMgpec/H72Z2GvUvCKHxi9JbIM4YuMMJhnkBk3I7f8L9BUMg5DO4wxvlzJ/4rWExEdlfg0ugDpgA== X-Received: by 2002:adf:94e2:: with SMTP id 89-v6mr24374375wrr.48.1533144545386; Wed, 01 Aug 2018 10:29:05 -0700 (PDT) Received: from ecklm-lapos.localdomain (ecklm-pi.sch.bme.hu. [152.66.179.182]) by smtp.gmail.com with ESMTPSA id s9-v6sm5156660wmc.34.2018.08.01.10.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 10:29:05 -0700 (PDT) From: =?utf-8?b?TcOhdMOpIEVja2w=?= To: netfilter-devel@vger.kernel.org Cc: arushisinghal19971997@gmail.com Subject: [PATCH nft 1/5] doc: data-types.txt: Wrap extra long lines to 80 chars Date: Wed, 1 Aug 2018 19:28:48 +0200 Message-Id: <559b1d5900fed93df4e6f51f6db493613bc81f6e.1533144099.git.ecklm94@gmail.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Signed-off-by: Máté Eckl --- doc/data-types.txt | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/doc/data-types.txt b/doc/data-types.txt index 1d4218e..57aa3a4 100644 --- a/doc/data-types.txt +++ b/doc/data-types.txt @@ -9,7 +9,9 @@ variable | - |=================== -The integer type is used for numeric values. It may be specified as decimal, hexadecimal or octal number. The integer type doesn't have a fixed size, its size is determined by the expression for which it is used. +The integer type is used for numeric values. It may be specified as decimal, +hexadecimal or octal number. The integer type doesn't have a fixed size, its +size is determined by the expression for which it is used. BITMASK TYPE ~~~~~~~~~~~~ @@ -35,7 +37,10 @@ variable | - |=================== -The string type is used for character strings. A string begins with an alphabetic character (a-zA-Z) followed by zero or more alphanumeric characters or the characters /, -, _ and .. In addition anything enclosed in double quotes (") is recognized as a string. +The string type is used for character strings. A string begins with an +alphabetic character (a-zA-Z) followed by zero or more alphanumeric characters +or the characters /, -, _ and .. In addition anything enclosed in double +quotes (") is recognized as a string. .String specification ---------------------- @@ -57,7 +62,9 @@ variable | integer |=================== -The link layer address type is used for link layer addresses. Link layer addresses are specified as a variable amount of groups of two hexadecimal digits separated using colons (:). +The link layer address type is used for link layer addresses. Link layer +addresses are specified as a variable amount of groups of two hexadecimal digits +separated using colons (:). .Link layer address specification ---------------------- @@ -76,7 +83,10 @@ ipv4_addr| integer |=================== -The IPv4 address type is used for IPv4 addresses. Addresses are specified in either dotted decimal, dotted hexadecimal, dotted octal, decimal, hexadecimal, octal notation or as a host name. A host name will be resolved using the standard system resolver. +The IPv4 address type is used for IPv4 addresses. Addresses are specified in +either dotted decimal, dotted hexadecimal, dotted octal, decimal, hexadecimal, +octal notation or as a host name. A host name will be resolved using the +standard system resolver. .IPv4 address specification ---------------------- @@ -98,7 +108,9 @@ ipv6_addr| integer |=================== -The IPv6 address type is used for IPv6 addresses. Addresses are specified as a host name or as hexadecimal halfwords separated by colons. Addresses might be enclosed in square brackets ("[]") to differentiate them from port numbers. +The IPv6 address type is used for IPv6 addresses. Addresses are specified as a +host name or as hexadecimal halfwords separated by colons. Addresses might be +enclosed in square brackets ("[]") to differentiate them from port numbers. .IPv6 address specificationIPv6 address specification with bracket notation ---------------------- @@ -120,7 +132,9 @@ boolean | integer |=================== -The boolean type is a syntactical helper type in user space. It's use is in the right-hand side of a (typically implicit) relational expression to change the expression on the left-hand side into a boolean check (usually for existence). + +The boolean type is a syntactical helper type in user space. It's use is in the +right-hand side of a (typically implicit) relational expression to change the +expression on the left-hand side into a boolean check (usually for existence). + The following keywords will automatically resolve into a boolean type with given value: The bitmask type (bitmask) is used for bitmasks. @@ -361,7 +375,8 @@ icmpv6_type | integer |=================== -The ICMPvX Code type abstraction is a set of values which overlap between ICMP and ICMPv6 Code types to be used from the inet family. +The ICMPvX Code type abstraction is a set of values which overlap between ICMP +and ICMPv6 Code types to be used from the inet family. .keywords may be used when specifying the ICMPvX code [options="header"] From patchwork Wed Aug 1 17:28:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TcOhdMOpIEVja2w=?= X-Patchwork-Id: 952315 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="eKGCjT4i"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41ggK50685z9sD9 for ; Thu, 2 Aug 2018 03:29:13 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407537AbeHATPw (ORCPT ); Wed, 1 Aug 2018 15:15:52 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:46055 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406417AbeHATPw (ORCPT ); Wed, 1 Aug 2018 15:15:52 -0400 Received: by mail-wr1-f68.google.com with SMTP id f12-v6so10979341wrv.12 for ; Wed, 01 Aug 2018 10:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3ZsLlLo8hh28t7wwjuyOsLJtK76WC16QuYmClNiZWrk=; b=eKGCjT4iGlLN51GLd0aiNjplilk2owiE+lqbQTRe3vF4eyzPQdpEBxqDvRUPmpcB40 ncHsXOWseQpY7zVg9kI8aw9cGBMmu35zqUeMMT3PHcbp6/5JXlGoyizNmitROO1OHgS3 wYX7ZcKDOLA5zcASPj8w0qyWgwnNqrVEPlmYoAxHSdk8/11V+MAJ8vQlNGSkuzfWcjEW xtlE3hqffr0RkfY5GfXnMD1CV5pRL+QwEAp/Vj2/qzIn+ABRq2D96gbkp+lcgAL/X+Vv 9a4bakFTbgK9N0QeXiCT1vYb/f/87UNjKIVllwHIhZ4YstjCyOyNNGVWSF0JJMGWD7Y2 EjmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3ZsLlLo8hh28t7wwjuyOsLJtK76WC16QuYmClNiZWrk=; b=GcbECBcyPxB406SCnUgUj90bRFQOMl/1M7p/wCdxFLVix42GtJxpcA4svKcXJBqVoE kiDcbiu7UveErEt2U7cN4BIVQaoJXQPd3mvfTcOamIvg/XTtX2XR7rSt9aINuaFoF82m 2WYiNc1TM9WR+iQ66NuXnrrG6TaoRTec7x54T4653/Ya6jkmmN+NUewrmkHpqX2DNSOq hf9n4lKFgwTGm+krl2lb5SwAAZyCcSjVSYVMrewq0MFSvQhg/nPtMwJAhm2mokbCuRBq dV2HW7Sj+X1EFCxDCM8hWQXTVLwUY4NNh5Oq1XkWcaOcqHW2s/VeIqZzHWJXMvRBVHBb KnIw== X-Gm-Message-State: AOUpUlEH6sNKW0I/7kB63FwwHKOjMCmyIyG9fRRnsPZQ2PpRByDnnQiY /qOXReBldhpqf1EGdNluUYBsvV6c X-Google-Smtp-Source: AAOMgpcftMx2W83wXrrhvLWjvD/qLhPZKgrqZCCxyOUdNuvYAFtEv75cp4Sa3peY8XnmblAloKzCzQ== X-Received: by 2002:adf:93c3:: with SMTP id 61-v6mr23946880wrp.18.1533144547453; Wed, 01 Aug 2018 10:29:07 -0700 (PDT) Received: from ecklm-lapos.localdomain (ecklm-pi.sch.bme.hu. [152.66.179.182]) by smtp.gmail.com with ESMTPSA id s9-v6sm5156660wmc.34.2018.08.01.10.29.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 10:29:07 -0700 (PDT) From: =?utf-8?b?TcOhdMOpIEVja2w=?= To: netfilter-devel@vger.kernel.org Cc: arushisinghal19971997@gmail.com Subject: [PATCH nft 2/5] doc: payload-expression.txt: Wrap extra long lines to 80 chars Date: Wed, 1 Aug 2018 19:28:49 +0200 Message-Id: <5c151a9f707f030002a8b3833d0c37afccac2b91.1533144099.git.ecklm94@gmail.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Signed-off-by: Máté Eckl --- doc/payload-expression.txt | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/doc/payload-expression.txt b/doc/payload-expression.txt index d454c95..3f47b4e 100644 --- a/doc/payload-expression.txt +++ b/doc/payload-expression.txt @@ -146,7 +146,12 @@ IPV6 HEADER EXPRESSION [verse] ip6 ['IPv6' 'header' 'field'] -This expression refers to the ipv6 header fields. Caution when using ip6 nexthdr, the value only refers to the next header, i.e. ip6 nexthdr tcp will only match if the ipv6 packet does not contain any extension headers. Packets that are fragmented or e.g. contain a routing extension headers will not be matched. Please use meta l4proto if you wish to match the real transport header and ignore any additional extension headers instead. +This expression refers to the ipv6 header fields. Caution when using ip6 +nexthdr, the value only refers to the next header, i.e. ip6 nexthdr tcp will +only match if the ipv6 packet does not contain any extension headers. Packets +that are fragmented or e.g. contain a routing extension headers will not be +matched. Please use meta l4proto if you wish to match the real transport header +and ignore any additional extension headers instead. .IPv6 header expression [options="header"] @@ -410,7 +415,14 @@ RAW PAYLOAD EXPRESSION [verse] *@* [base,offset,length] -The raw payload expression instructs to load lengthbits starting at offsetbits. Bit 0 refers to the very first bit -- in the C programming language, this corresponds to the topmost bit, i.e. 0x80 in case of an octet. They are useful to match headers that do not have a human-readable template expression yet. Note that nft will not add dependencies for Raw payload expressions. If you e.g. want to match protocol fields of a transport header with protocol number 5, you need to manually exclude packets that have a different transport header, for instance my using meta l4proto 5 before the raw expression. +The raw payload expression instructs to load lengthbits starting at offsetbits. +Bit 0 refers to the very first bit -- in the C programming language, this +corresponds to the topmost bit, i.e. 0x80 in case of an octet. They are useful +to match headers that do not have a human-readable template expression yet. Note +that nft will not add dependencies for Raw payload expressions. If you e.g. want +to match protocol fields of a transport header with protocol number 5, you need +to manually exclude packets that have a different transport header, for instance +my using meta l4proto 5 before the raw expression. .Support payload protocol bases [options="header"] @@ -524,7 +536,13 @@ CONNTRACK EXPRESSIONS ~~~~~~~~~~~~~~~~~~~~~ Conntrack expressions refer to meta data of the connection tracking entry associated with a packet. + -There are three types of conntrack expressions. Some conntrack expressions require the flow direction before the conntrack key, others must be used directly because they are direction agnostic. The *packets*, *bytes* and *avgpkt* keywords can be used with or without a direction. If the direction is omitted, the sum of the original and the reply direction is returned. The same is true for the *zone*, if a direction is given, the zone is only matched if the zone id is tied to the given direction. + +There are three types of conntrack expressions. Some conntrack expressions +require the flow direction before the conntrack key, others must be used +directly because they are direction agnostic. The *packets*, *bytes* and +*avgpkt* keywords can be used with or without a direction. If the direction is +omitted, the sum of the original and the reply direction is returned. The same +is true for the *zone*, if a direction is given, the zone is only matched if the +zone id is tied to the given direction. + [verse] *ct* {state | direction | status | mark | expiration | helper | label | l3proto | protocol | bytes | packets | avgpkt | zone} From patchwork Wed Aug 1 17:28:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TcOhdMOpIEVja2w=?= X-Patchwork-Id: 952313 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="e9lNz0Id"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41ggK321LXz9sD9 for ; Thu, 2 Aug 2018 03:29:11 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407539AbeHATPx (ORCPT ); Wed, 1 Aug 2018 15:15:53 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:38848 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407064AbeHATPw (ORCPT ); Wed, 1 Aug 2018 15:15:52 -0400 Received: by mail-wr1-f65.google.com with SMTP id v14-v6so20924839wro.5 for ; Wed, 01 Aug 2018 10:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vWVrkwYwaNQYrlIviWA9C9Eib5qjiVl2qMMiP5I2Z3s=; b=e9lNz0IdXJstpvINC8xHTeeNaUVMjMMqpLRnm8BTKquBk0kehdOml9Awy0oWMaCzJ1 X9wm/mKN6jKUJmUz4zN/CmDnibYoButjVTVeiE4DLP8Bch0FdQYa7WFmQaUAhwxp6MYI g1fx6sTTA0kKlngz/trgv1qe1lC5EIx4Rm6cmbJNrD8vq7hy5AzT03PE83ng3msOtLUr WZhsLXa8XReOCx0sgLXvRn35kYjn2yx9J57p3Kf8ufaFaGgwBYJ9whiGK1Vp0GlYlJUo fVVcFi8cJIdfpr+ftSz6KBz/yUYMI+mfyYj2Xie3Pqj+Z6P3Lk3aViBBUcMJC5lzNrtR M//A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vWVrkwYwaNQYrlIviWA9C9Eib5qjiVl2qMMiP5I2Z3s=; b=ra4TzP/PrqleU8QoOTpsdbZ66X17UhFl3SpwpDQAEY29+JwWRTxsUkiZtTrODPEYtv xllphz7E0iuh8TQLM0Qy3wCkXFfnGFZ7oqWYDRYNRbJmrRm069VrIIsQOs1eQ/ufPF6U a9vEm17mUJfTZSKotBwFzGsaymDcAjzXJxpYfSinZv0B9wlDUfZ8xKBkdcTAkCyit0hK z70zirRoF1IvYRQwynhqcpwK/6T10JxX/qwgtaC0GI0BpNsKxOrDRTypxExcnSbyr95K DXyaOAfAsonighywNjpsaYbubOpWcO+Gi8b/hTn7Fv64WfE9/x7VQKbjeCFYot8Fedjq NcCQ== X-Gm-Message-State: AOUpUlEBme+9NmGxewmMHUa+TT95S7ZfWlhPnuhrerXyGu0RuTqf25Xi i49tFd7bRbxMOI6LWzQfoR+IRD6V X-Google-Smtp-Source: AAOMgpf9vGZw5GV6DIv3BxHvBkJ5YiNH5JGYVUsWr5gqCxVNNeqa4LKspUm64iDBs9U+FMenWjQtMg== X-Received: by 2002:adf:9954:: with SMTP id x78-v6mr25858183wrb.178.1533144548039; Wed, 01 Aug 2018 10:29:08 -0700 (PDT) Received: from ecklm-lapos.localdomain (ecklm-pi.sch.bme.hu. [152.66.179.182]) by smtp.gmail.com with ESMTPSA id s9-v6sm5156660wmc.34.2018.08.01.10.29.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 10:29:07 -0700 (PDT) From: =?utf-8?b?TcOhdMOpIEVja2w=?= To: netfilter-devel@vger.kernel.org Cc: arushisinghal19971997@gmail.com Subject: [PATCH nft 3/5] doc: primary-expression.txt: Wrap extra long lines to 80 chars Date: Wed, 1 Aug 2018 19:28:50 +0200 Message-Id: X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Signed-off-by: Máté Eckl --- doc/primary-expression.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/doc/primary-expression.txt b/doc/primary-expression.txt index 162f32f..50093b4 100644 --- a/doc/primary-expression.txt +++ b/doc/primary-expression.txt @@ -8,7 +8,12 @@ skuid | skgid | nftrace | rtclassid | ibrname | obrname | pkttype | cpu A meta expression refers to meta data associated with a packet. -There are two types of meta expressions: unqualified and qualified meta expressions. Qualified meta expressions require the meta keyword before the meta key, unqualified meta expressions can be specified by using the meta key directly or as qualified meta expressions. Meta l4proto is useful to match a particular transport protocol that is part of either an IPv4 or IPv6 packet. It will also skip any IPv6 extension headers present in an IPv6 packet. +There are two types of meta expressions: unqualified and qualified meta +expressions. Qualified meta expressions require the meta keyword before the meta +key, unqualified meta expressions can be specified by using the meta key +directly or as qualified meta expressions. Meta l4proto is useful to match a +particular transport protocol that is part of either an IPv4 or IPv6 packet. It +will also skip any IPv6 extension headers present in an IPv6 packet. .Meta expression types [options="header"] @@ -127,7 +132,9 @@ SOCKET EXPRESSION [verse] socket {transparent} -Socket expression can be used to search for an existing open TCP/UDP socket and its attributes that can be associated with a packet. It looks for an established or non-zero bound listening socket (possibly with a non-local address). +Socket expression can be used to search for an existing open TCP/UDP socket and +its attributes that can be associated with a packet. It looks for an established +or non-zero bound listening socket (possibly with a non-local address). .Available socket attributes [options="header"] @@ -154,7 +161,10 @@ FIB EXPRESSIONS [verse] fib {saddr | daddr | {mark | iif | oif}} {oif | oifname | type} -A fib expression queries the fib (forwarding information base) to obtain information such as the output interface index a particular address would use. The input is a tuple of elements that is used as input to the fib lookup functions. +A fib expression queries the fib (forwarding information base) to obtain +information such as the output interface index a particular address would use. +The input is a tuple of elements that is used as input to the fib lookup +functions. .fib expression specific types [options="header"] From patchwork Wed Aug 1 17:28:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TcOhdMOpIEVja2w=?= X-Patchwork-Id: 952314 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ccxaCjLM"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41ggK40grzz9sDB for ; Thu, 2 Aug 2018 03:29:12 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407540AbeHATPx (ORCPT ); Wed, 1 Aug 2018 15:15:53 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:43189 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2407328AbeHATPx (ORCPT ); Wed, 1 Aug 2018 15:15:53 -0400 Received: by mail-wr1-f65.google.com with SMTP id b15-v6so20885486wrv.10 for ; Wed, 01 Aug 2018 10:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2+3VmNj64zKYq9hy3pyXKGP3IHRfraIAS6SiQCZHcJY=; b=ccxaCjLMPg3F8i44/ntJFyJw3LqjbgHVF53eZMbTZ1Bw/9GELuTL1nUP5O03ovoUDr IYHAxvvDuUbWgMrgdqF8jOzgONpPgV8hnO6anSG+bJAnyhcWddR18ui3SQubxHYGYazL 4CGscYFt/96vVxRIQXGMFC2FDWl2VMF1uOn5j7hF2W3e4XLIWuM37t5wsuuRNzphCxm+ RJuaja3BPiOZMiBHhTKGdW2yw4MGuBrHrZTlS+K2cnnA7dQ9TEneD2Wug5giMCpQYlp9 4yVsxN6VO74panNEwrBf9CS10XT3cffZz4iA+mwR9psR+RGHMgMCEOwqmJl906/Xe8TZ v/UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2+3VmNj64zKYq9hy3pyXKGP3IHRfraIAS6SiQCZHcJY=; b=Ehfuzfim/yJA8hU+EJhqaZK5UP4CiKNxrKJ8arU4CpvM3UnQRLa4nxWW+2z9PpoFSR vIiZe3DE+bITWSnFMxBQf8j3ZmKdTPZfv8RVw3AB9Pm8BHZVGpbaEmWa5Dn9v3QfwVYV SB8aVAnSpxM0L0ULZhmR8u6XbTR1rZ+/zxqLXqNuvrmXI/ZlpzOni8qPL/7QDLzyFJyE Q9m4L7k2+xUV1glOx8AIiruE48SK0PHclcE+njcCeVbmSg3HZeXKw021C8vODZ8XlU/x ep0/76O5WW+Y+Qs97DukDR1wuknZ0muBpAdWgb5yUd9a+PUhbCaKzD8zAxch6iyYdL/u bddA== X-Gm-Message-State: AOUpUlHRcUWAE0LD1CXgZpNK+pSgrt+Zb6MHEYR18mv+/qJ9symiPL/D j8eBUMSCwpWQt5O//RHuVDWajchp X-Google-Smtp-Source: AAOMgpe1btCm+Qhz13c6fiRqo5COxaOvE0VV8KlZuceW082gM9OaaM0iP/pytr1eTiajPwzVMBaIFQ== X-Received: by 2002:adf:adc9:: with SMTP id w67-v6mr24077318wrc.135.1533144548677; Wed, 01 Aug 2018 10:29:08 -0700 (PDT) Received: from ecklm-lapos.localdomain (ecklm-pi.sch.bme.hu. [152.66.179.182]) by smtp.gmail.com with ESMTPSA id s9-v6sm5156660wmc.34.2018.08.01.10.29.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 10:29:08 -0700 (PDT) From: =?utf-8?b?TcOhdMOpIEVja2w=?= To: netfilter-devel@vger.kernel.org Cc: arushisinghal19971997@gmail.com Subject: [PATCH nft 4/5] doc: stateful-objects.txt: Wrap extra long lines to 80 chars Date: Wed, 1 Aug 2018 19:28:51 +0200 Message-Id: X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Signed-off-by: Máté Eckl --- doc/stateful-objects.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/doc/stateful-objects.txt b/doc/stateful-objects.txt index 9d99264..57bf627 100644 --- a/doc/stateful-objects.txt +++ b/doc/stateful-objects.txt @@ -3,7 +3,11 @@ CT [verse] *ct* helper 'helper' {type 'type' protocol 'protocol' ; [l3proto 'family' ;] } -Ct helper is used to define connection tracking helpers that can then be used in combination with the *ct helper set* statement. 'type' and 'protocol' are mandatory, l3proto is derived from the table family by default, i.e. in the inet table the kernel will try to load both the ipv4 and ipv6 helper backends, if they are supported by the kernel. +Ct helper is used to define connection tracking helpers that can then be used in +combination with the *ct helper set* statement. 'type' and 'protocol' are +mandatory, l3proto is derived from the table family by default, i.e. in the inet +table the kernel will try to load both the ipv4 and ipv6 helper backends, if +they are supported by the kernel. .conntrack helper specifications [options="header"] @@ -22,7 +26,8 @@ address family (e.g. ip) .defining and assigning ftp helper ---------------------------------- -Unlike iptables, helper assignment needs to be performed after the conntrack lookup has completed, for example with the default 0 hook priority. +Unlike iptables, helper assignment needs to be performed after the conntrack +lookup has completed, for example with the default 0 hook priority. table inet myhelpers { ct helper ftp-standard { From patchwork Wed Aug 1 17:28:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?TcOhdMOpIEVja2w=?= X-Patchwork-Id: 952316 X-Patchwork-Delegate: pablo@netfilter.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netfilter-devel-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="sdpvAC3f"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41ggcX6QW9z9s3x for ; Thu, 2 Aug 2018 03:42:36 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407117AbeHATPz (ORCPT ); Wed, 1 Aug 2018 15:15:55 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:43191 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406417AbeHATPz (ORCPT ); Wed, 1 Aug 2018 15:15:55 -0400 Received: by mail-wr1-f66.google.com with SMTP id b15-v6so20885517wrv.10 for ; Wed, 01 Aug 2018 10:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZRVWasfu9nUZupaRZC5dV0x7zA9OiV/xU3Fd3PNBdq8=; b=sdpvAC3fDM4HxD9ATq31Xt/uaKqHT7t0AfR1SbNnLO/GFCDn9+4m38C4zTkS/zcBdQ MOEgCxLhtgMamdNVyqh/+ME1k7n0zVGtI3avq+YApaYWdyOzJcQntrfD3VZ5Pu52rgUU 5uQfffGUvNjfCWSjLEhkJOHDAHReOhWycvJIZkglPsHrloqxdTqcKh+Rffb2Qc1dAzAn 1/c0w2VVl3b0wqka5IbnZTCtPnWklumeK0xbgRyBCKKmiEzgon0wI7IwKrZMwhnMoGVK jIc7ZJ0fSJmxKruqM3WsHIIAuqP33x4vLAsy8LkIMGrUZqVt3HTAvujeFxJ2gZyBT04h iMHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZRVWasfu9nUZupaRZC5dV0x7zA9OiV/xU3Fd3PNBdq8=; b=L7RjbZUvPC/Te1PSzfiKE0jWFcjP3dVxms/cYSnnwxcqT3jgWrXx13Bc4C3nR2K15y XT3YvvPzAvuf5mdX5Cw4pgGoNYuY25/jbWNHK5usDpwxMGBVOVOLWOWTBkilEW9RCIoe kSsp96lXCNlVhD4oioePSHP9PO9UEK1J0GRllzjC/6I+Lhlg4RbpQbrV+3sKdbMnhmiA bLqrfHolM6WiizYru4da4AfLH9OMHlnMhBvg3jCecUxM0oEz13HKGGwEIe3/A8C58qQB rnEVMOFVcNUwVL/Mgi+cAZJXFZDezifN7Za+8I8ECFXWq/drTNYShNfxi+H3Z1gXyPrX F+WA== X-Gm-Message-State: AOUpUlFbkrW+kyIZgrP8CbEtWBc82/jHbpxzoW123AQn+H8Ow+nk2Ebr uj/mai3fk4BtpZtNeY/rpfVNBbe7 X-Google-Smtp-Source: AAOMgpeRw88ntJdTjfHLRZI+dTDzHkrLZUR1wIjRW/0lmlX1DrLDhojJrhQE0MOImeEBAieRZmHNOg== X-Received: by 2002:adf:d08c:: with SMTP id y12-v6mr25178373wrh.152.1533144549239; Wed, 01 Aug 2018 10:29:09 -0700 (PDT) Received: from ecklm-lapos.localdomain (ecklm-pi.sch.bme.hu. [152.66.179.182]) by smtp.gmail.com with ESMTPSA id s9-v6sm5156660wmc.34.2018.08.01.10.29.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 10:29:08 -0700 (PDT) From: =?utf-8?b?TcOhdMOpIEVja2w=?= To: netfilter-devel@vger.kernel.org Cc: arushisinghal19971997@gmail.com Subject: [PATCH nft 5/5] doc: statements.txt: Wrap extra long lines to 80 chars Date: Wed, 1 Aug 2018 19:28:52 +0200 Message-Id: X-Mailer: git-send-email 2.18.0 In-Reply-To: References: MIME-Version: 1.0 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Signed-off-by: Máté Eckl --- doc/statements.txt | 108 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 83 insertions(+), 25 deletions(-) diff --git a/doc/statements.txt b/doc/statements.txt index 499b573..bcf3cc2 100644 --- a/doc/statements.txt +++ b/doc/statements.txt @@ -11,9 +11,14 @@ The verdict statement alters control flow in the ruleset and issues policy decis *drop*:: Terminate ruleset evaluation and drop the packet. *queue*:: Terminate ruleset evaluation and queue the packet to userspace. *continue*:: Continue ruleset evaluation with the next rule. FIXME -*return*:: Return from the current chain and continue evaluation at the next rule in the last chain. If issued in a base chain, it is equivalent to *accept*. -*jump* 'chain':: Continue evaluation at the first rule in 'chain'. The current position in the ruleset is pushed to a call stack and evaluation will continue there when the new chain is entirely evaluated of a *return* verdict is issued. -*goto* 'chain':: Similar to *jump*, but the current position is not pushed to the call stack, meaning that after the new chain evaluation will continue at the last chain instead of the one containing the goto statement. +*return*:: Return from the current chain and continue evaluation at the + next rule in the last chain. If issued in a base chain, it is equivalent to *accept*. +*jump* 'chain':: Continue evaluation at the first rule in 'chain'. The current + position in the ruleset is pushed to a call stack and evaluation will continue + there when the new chain is entirely evaluated of a *return* verdict is issued. +*goto* 'chain':: Similar to *jump*, but the current position is not pushed to the + call stack, meaning that after the new chain evaluation will continue at the last + chain instead of the one containing the goto statement. .Verdict statements ------------------- @@ -26,7 +31,8 @@ filter input iif eth0 drop PAYLOAD STATEMENT ~~~~~~~~~~~~~~~~~ -The payload statement alters packet content. It can be used for example to set ip DSCP (differv) header field or ipv6 flow labels. +The payload statement alters packet content. It can be used for example to +set ip DSCP (differv) header field or ipv6 flow labels. .route some packets instead of bridging --------------------------------------- @@ -42,7 +48,9 @@ ip forward ip dscp set 42 EXTENSION HEADER STATEMENT ~~~~~~~~~~~~~~~~~~~~~~~~~~ -The extension header statement alters packet content in variable-sized headers. This can currently be used to alter the TCP Maximum segment size of packets, similar to TCPMSS. +The extension header statement alters packet content in variable-sized headers. +This can currently be used to alter the TCP Maximum segment size of packets, +similar to TCPMSS. .change tcp mss --------------- @@ -57,7 +65,15 @@ LOG STATEMENT log [prefix quoted_string] [level syslog-level] [flags log-flags] log group nflog_group [prefix quoted_string] [queue-threshold value] [snaplen size] -The log statement enables logging of matching packets. When this statement is used from a rule, the Linux kernel will print some information on all matching packets, such as header fields, via the kernel log (where it can be read with dmesg(1) or read in the syslog). If the group number is specified, the Linux kernel will pass the packet to nfnetlink_log which will multicast the packet through a netlink socket to the specified multicast group. One or more userspace processes may subscribe to the group to receive the packets, see libnetfilter_queue documentation for details. This is a non-terminating statement, so the rule evaluation continues after the packet is logged. +The log statement enables logging of matching packets. When this statement is +used from a rule, the Linux kernel will print some information on all matching +packets, such as header fields, via the kernel log (where it can be read with +dmesg(1) or read in the syslog). If the group number is specified, the Linux +kernel will pass the packet to nfnetlink_log which will multicast the packet +through a netlink socket to the specified multicast group. One or more userspace +processes may subscribe to the group to receive the packets, see +libnetfilter_queue documentation for details. This is a non-terminating +statement, so the rule evaluation continues after the packet is logged. .log statement options [options="header"] @@ -116,7 +132,11 @@ REJECT STATEMENT *reject* [ with {icmp | icmpv6 | icmpx} type {icmp_code | icmpv6_code | icmpx_code} ] *reject* [ with tcp reset ] -A reject statement is used to send back an error packet in response to the matched packet otherwise it is equivalent to drop so it is a terminating statement, ending rule traversal. This statement is only valid in the input, forward and output chains, and user-defined chains which are only called from those chains. +A reject statement is used to send back an error packet in response to the +matched packet otherwise it is equivalent to drop so it is a terminating +statement, ending rule traversal. This statement is only valid in the input, +forward and output chains, and user-defined chains which are only called from +those chains. .different ICMP reject variants are meant for use in different table families [options="header"] @@ -133,9 +153,12 @@ inet| icmpx_code |================== -For a description of the different types and a list of supported keywords refer to DATA TYPES section above. The common default reject value is *port-unreachable*. + +For a description of the different types and a list of supported keywords refer +to DATA TYPES section above. The common default reject value is +*port-unreachable*. + -Note that in bridge family, reject statement is only allowed in base chains which hook into input or prerouting. +Note that in bridge family, reject statement is only allowed in base chains +which hook into input or prerouting. COUNTER STATEMENT ~~~~~~~~~~~~~~~~~ @@ -151,7 +174,10 @@ The conntrack statement can be used to set the conntrack mark and conntrack labe [verse] *ct* {mark | event | label | zone} set 'value' -The ct statement sets meta data associated with a connection. The zone id has to be assigned before a conntrack lookup takes place, i.e. this has to be done in prerouting and possibly output (if locally generated packets need to be placed in a distinct zone), with a hook priority of -300. +The ct statement sets meta data associated with a connection. The zone id +has to be assigned before a conntrack lookup takes place, i.e. this has to be +done in prerouting and possibly output (if locally generated packets need to be +placed in a distinct zone), with a hook priority of -300. .Conntrack statement types [options="header"] @@ -200,7 +226,8 @@ ct event set new,related,destroy META STATEMENT ~~~~~~~~~~~~~~ -A meta statement sets the value of a meta expression. The existing meta fields are: priority, mark, pkttype, nftrace. + +A meta statement sets the value of a meta expression. The existing meta fields +are: priority, mark, pkttype, nftrace. + meta {mark | priority | pkttype | nftrace} set 'value' + @@ -230,7 +257,10 @@ LIMIT STATEMENT *limit* rate [over] 'packet_number' / {second | minute | hour | day} [burst 'packet_number' packets] *limit* rate [over] 'byte_number' {bytes | kbytes | mbytes} / {second | minute | hour | day | week} [burst 'byte_number' bytes] -A limit statement matches at a limited rate using a token bucket filter. A rule using this statement will match until this limit is reached. It can be used in combination with the log statement to give limited logging. The over keyword, that is optional, makes it match over the specified rate. +A limit statement matches at a limited rate using a token bucket filter. A rule +using this statement will match until this limit is reached. It can be used in +combination with the log statement to give limited logging. The over keyword, +that is optional, makes it match over the specified rate. .limit statement values [options="header"] @@ -258,20 +288,35 @@ NAT STATEMENTS The nat statements are only valid from nat chain types. + -The *snat* and *masquerade* statements specify that the source address of the packet should be modified. While *snat* is only valid in the postrouting and input chains, *masquerade* makes sense only in postrouting. The dnat and redirect statements are only valid in the prerouting and output chains, they specify that the destination address of the packet should be modified. You can use nonbase chains which are called from base chains of nat chain type too. All future packets in this connection will also be mangled, and rules should cease being examined. +The *snat* and *masquerade* statements specify that the source address of the +packet should be modified. While *snat* is only valid in the postrouting and +input chains, *masquerade* makes sense only in postrouting. The dnat and +redirect statements are only valid in the prerouting and output chains, they +specify that the destination address of the packet should be modified. You can +use nonbase chains which are called from base chains of nat chain type too. +All future packets in this connection will also be mangled, and rules should +cease being examined. -The *masquerade* statement is a special form of snat which always uses the outgoing interface's IP address to translate to. It is particularly useful on gateways with dynamic (public) IP addresses. +The *masquerade* statement is a special form of snat which always uses the +outgoing interface's IP address to translate to. It is particularly useful on +gateways with dynamic (public) IP addresses. -The *redirect* statement is a special form of dnat which always translates the destination address to the local host's one. It comes in handy if one only wants to alter the destination port of incoming traffic on different interfaces. +The *redirect* statement is a special form of dnat which always translates the +destination address to the local host's one. It comes in handy if one only wants +to alter the destination port of incoming traffic on different interfaces. -Note that all nat statements require both prerouting and postrouting base chains to be present since otherwise packets on the return path won't be seen by netfilter and therefore no reverse translation will take place. +Note that all nat statements require both prerouting and postrouting base chains +to be present since otherwise packets on the return path won't be seen by +netfilter and therefore no reverse translation will take place. .NAT statement values [options="header"] |================== |Expression| Description| Type |address| -Specifies that the source/destination address of the packet should be modified. You may specify a mapping to relate a list of tuples composed of arbitrary expression key with address value. | +Specifies that the source/destination address of the packet should be modified. +You may specify a mapping to relate a list of tuples composed of arbitrary +expression key with address value. | ipv4_addr, ipv6_addr, e.g. abcd::1234, or you can use a mapping, e.g. meta mark map { 10 : 192.168.1.2, 20 : 192.168.1.3 } |port| Specifies that the source/destination address of the packet should be modified. | @@ -313,14 +358,19 @@ add rule nat prerouting tcp dport 22 redirect to :2222 FLOW OFFLOAD STATEMENT ~~~~~~~~~~~~~~~~~~~~~~ -A flow offload statement allows us to select what flows you want to accelerate forwarding through layer 3 network stack bypass. -You have to specify the flowtable name where you want to offload this flow. +A flow offload statement allows us to select what flows you want to accelerate +forwarding through layer 3 network stack bypass. You have to specify the +flowtable name where you want to offload this flow. *flow offload* @flowtable QUEUE STATEMENT ~~~~~~~~~~~~~~~ -This statement passes the packet to userspace using the nfnetlink_queue handler. The packet is put into the queue identified by its 16-bit queue number. Userspace can inspect and modify the packet if desired. Userspace must then drop or re-inject the packet into the kernel. See libnetfilter_queue documentation for details. +This statement passes the packet to userspace using the nfnetlink_queue handler. +The packet is put into the queue identified by its 16-bit queue number. +Userspace can inspect and modify the packet if desired. Userspace must then drop +or re-inject the packet into the kernel. See libnetfilter_queue documentation +for details. [verse] *queue* [num 'queue_number'] [bypass] @@ -346,14 +396,16 @@ unsigned integer (16 bit) |================== |Flag | Description |bypass | -Let packets go through if userspace application cannot back off. Before using this flag, read libnetfilter_queue documentation for performance tuning recommendations. +Let packets go through if userspace application cannot back off. Before using +this flag, read libnetfilter_queue documentation for performance tuning recommendations. |fanout | Distribute packets between several queues. |=============================== DUP STATEMENT ~~~~~~~~~~~~~ -The dup statement is used to duplicate a packet and send the copy to a different destination. +The dup statement is used to duplicate a packet and send the copy to a different +destination. [verse] *dup* to 'device' @@ -387,14 +439,20 @@ dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" } FWD STATEMENT ~~~~~~~~~~~~~ -The fwd statement is used to redirect a raw packet to another interface. It is only available in the netdev family ingress hook. -It is similar to the dup statement except that no copy is made. +The fwd statement is used to redirect a raw packet to another interface. It is +only available in the netdev family ingress hook. It is similar to the dup +statement except that no copy is made. *fwd* to 'device' SET STATEMENT ~~~~~~~~~~~~~ -The set statement is used to dynamically add or update elements in a set from the packet path. The set setname must already exist in the given table and must have been created with the dynamic flag. Furthermore, these sets must specify both a maximum set size (to prevent memory exhaustion) and a timeout (so that number of entries in set will not grow indefinitely). The set statement can be used to e.g. create dynamic blacklists. +The set statement is used to dynamically add or update elements in a set from +the packet path. The set setname must already exist in the given table and must +have been created with the dynamic flag. Furthermore, these sets must specify +both a maximum set size (to prevent memory exhaustion) and a timeout (so that +number of entries in set will not grow indefinitely). The set statement can be +used to e.g. create dynamic blacklists. [verse] {add | update} '@setname' { 'expression' [timeout 'timeout'] [comment 'string'] }