This page provides an overview of Funtoo Linux sub-architectures (also called ''subarches'',) designed for quick and easy reference. While this information is available in other places, such as Wikipedia, it often takes some time to study and cross-reference the various articles to get a good understanding of each type of sub-architecture, and this information generally isn't all collected neatly in one place. That is the purpose of this page. When possible, links to more detailed Wikipedia pages are provided. You are encouraged to help maintain this page as well as the Wikipedia articles referenced here.

+

|Repository=Gentoo Portage Tree

+

}}

+

=== What is nftables? ===

+

'''nftables''' is the successor to [[iptables]]. It replaces the existing iptables, ip6tables, arptables and ebtables framework. It uses the Linux kernel and a new userspace utility called nft. nftables provides a compatibility layer for the ip(6)tables and framework.

−

== 64-bit Suport (Generic) ==

+

==Introduction==

+

As with the iptables framework, nftables is build upon rules which specify the actions. These rules are attached to chains. A chain can contain a collection of rules and is registered into the netfilter hooks. Chains are stored inside tables. A table is specific for one of the layer 3 protocols. One of the main differences with iptables is that there are no predefined tables and chains anymore.

−

=== generic_64 ===

+

===Tables===

+

A table is nothing more than a container for your chains. With nftables there are no predefined tables (filter, raw, mangle...) anymore. You are free to recreate the iptables-like structure, but anything might do.

+

Currently there are 5 different families of tables:

+

* '''ip''': Used for IPv4 related chains;

+

* '''ip6''': Used for IPv6 related chains;

+

* '''arp''': Used for ARP related chains;

+

* '''bridge''': Used for bridging related chains;

+

* '''inet''': Mixed ipv4/ipv6 chains (kernel 3.14 and up).

−

The '''generic_64''' subarch is designed to support 64-bit PC-compatible CPUs, such as the [[Wikipedia:AMD_K8|AMD K8-series processors]], which were introduced in late 2003. They were notable as the first processors that supported the [[Wikipedia:X86-64|AMD64 (also called X86-64) 64-bit instruction set]] for PC-compatible systems, which was introduced as a backwards-compatible 64-bit alternative to Intel's IA-64 architecture. Intel followed suit and also began supporting this 64-bit instruction set, which they called "[[Wikipedia:X86-64#Intel_64|Intel 64]]", by releasing X86-64 64-bit compatible CPUs from mid-2004 onwards (See [[Wikipedia:X86-64#Intel_64_implementations|Intel 64 implementations]].)

+

It is not hard to recognize the old tables framework in these tables. The only new one is the inet table which is used for both IPv4 and IPv6 traffic. It should make firewalling for dual-stack hosts easier by combining the rules for IPv4 and IPv6.

−

AMD desktop 64-bit CPUs include the Athlon 64, Athlon 64 FX, Athlon 64 X2, Athlon X2, Turion 64, Turion 64 X2 and Sempron series processors. AMD server processors were released under the Opteron brand and have codenames SledgeHammer, Venus, Troy, Athens, Denmark, Italy, Egypt, Santa Ana and Santa Rosa. All Opterons released through late 2006 were based on the K8 microarchitecture with original X86-64 instructions.

+

===Chains===

+

Chains are used to group together rules. As with the tables, nftables does not have any predefined chains. Chains are grouped in base and non-base types. Base chains are registered in one of the netfilter hooks. A base chain has a hook its registered with, a type and a priority. Non-base chains are not attached to a hook and they don't see any traffic by default. They can be used to arrange a rule-set in a tree of chains.

+

There are currently three types of chains:

+

* '''filter''': for filtering packets

+

* '''route''': for rerouting packets

+

* '''nat''': for performing Network Address Translation. Only the first packet of a flow hits this chain, making it impossible to use it for filtering.

+

The hooks that can be used are:

+

* '''prerouting''': This is before the routing decision, all packets entering the machine hits this chain

+

* '''input''': All packets for the local system hits this hook

+

* '''forward''': Packets not for the local system, those that need to be forwarded hits this hook

+

* '''output''': Packets that originate from the local system pass this hook

+

* '''postrouting''': This hook is after the routing decision, all packets leaving the machine hits this chain

+

{{Note|The ARP address family only supports the input and output hook}}

+

{{Note|The bridge address family only seems to supports the input, forward and output hook}}

−

== 64-bit AMD Processors ==

+

====Priorities====

−

=== amd64-k10 ===

+

{{Note|Priorities do not currently appear to have any effect on which chain sees packets first.}}

−

The '''amd64-k10''' subarch provides support for the [[Wikipedia:AMD_10h|AMD Family 10h processors]], which were released in late 2007 as a successor to the AMD K8 series processors.

+

{{Note|Since the priority seems to be an unsigned integer, negative priorities will be converted into very high priorities.}}

Rules specify which action has to be taken for which packets. Rules are attached to chains. Each rule can has an expression to match packets with and one or multiple actions when matching. Main differences with iptables is that it is possible to specify multiple actions and that by default counters are off. It must be specified explicitly in rules if you want packet- and byte-counters for a rule.

+

Each rule has a unique handle number by which it can be distinguished.

+

The following matches are available:

+

* '''ip''': IP protocol

+

* '''ip6''': IPv6 protocol

+

* '''tcp''': TCP protocol

+

* '''udp''': UDP protocol

+

* '''udplite''': UDP-lite protocol

+

* '''sctp''': SCTP protocol

+

* '''dccp''': DCCP protocol

+

* '''ah''': Authentication headers

+

* '''esp''': Encrypted security payload headers

+

* '''ipcomp''': IPcomp headers

+

* '''icmp''': icmp protocol

+

* '''icmpv6''': icmpv6 protocol

+

* '''ct''': Connection tracking

+

* '''meta''': meta properties such as interfaces

−

=== amd64-bulldozer ===

+

====Matches====

+

{|class=wikitable

+

| Match

+

| Arguments

+

| Description/Example

+

|-

+

| rowspan="11" | '''ip'''

+

| version

+

| Ip Header version

+

|-

+

| hdrlength

+

| IP header length

+

|-

+

| tos

+

|Type of Service

+

|-

+

| length

+

| Total packet length

+

|-

+

| id

+

| IP ID

+

|-

+

| frag-off

+

| Fragmentation offset

+

|-

+

| ttl

+

| Time to live

+

|-

+

| protocol

+

| Upper layer protocol

+

|-

+

| checksum

+

| IP header checksum

+

|-

+

| saddr

+

| Source address

+

|-

+

| daddr

+

| Destination address

+

|-

+

| rowspan="8" | '''ip6'''

+

| version

+

| IP header version

+

|-

+

| priority

+

|

+

|-

+

| flowlabel

+

| Flow label

+

|-

+

| length

+

| Payload length

+

|-

+

| nexthdr

+

| Next header type (Upper layer protocol number)

+

|-

+

| hoplimit

+

| Hop limit

+

|-

+

|saddr

+

| Source Address

+

|-

+

|daddr

+

| Destination Address

+

|-

+

| rowspan="9" | '''tcp'''

+

| sport

+

| Source port

+

|-

+

| dport

+

| Destination port

+

|-

+

| sequence

+

| Sequence number

+

|-

+

| ackseq

+

| Acknowledgement number

+

|-

+

| doff

+

| Data offset

+

|-

+

| flags

+

| TCP flags

+

|-

+

| window

+

| Window

+

|-

+

| checksum

+

| Checksum

+

|-

+

| urgptr

+

| Urgent pointer

+

|-

+

| rowspan="4" | '''udp'''

+

| sport

+

| Source port

+

|-

+

| dport

+

| destination port

+

|-

+

| length

+

| Total packet length

+

|-

+

| checksum

+

| Checksum

+

|-

+

| rowspan="4" | '''udplite'''

+

| sport

+

| Source port

+

|-

+

| dport

+

| destination port

+

|-

+

| cscov

+

| Checksum coverage

+

|-

+

| checksum

+

| Checksum

+

|-

+

| rowspan="4" |'''sctp'''

+

| sport

+

| Source port

+

|-

+

| dport

+

| destination port

+

|-

+

|vtag

+

|Verification tag

+

|-

+

| checksum

+

| Checksum

+

|-

+

| rowspan="2" |'''dccp'''

+

| sport

+

| Source port

+

|-

+

| dport

+

| destination port

+

|-

+

| rowspan="4" |'''ah'''

+

| nexthdr

+

| Next header protocol (Upper layer protocol)

+

|-

+

| hdrlength

+

| AH header length

+

|-

+

| spi

+

| Security Parameter Index

+

|-

+

| sequence

+

| Sequence Number

+

|-

+

| rowspan="2" | '''esp'''

+

| spi

+

| Security Parameter Index

+

|-

+

| sequence

+

| Sequence Number

+

|-

+

| rowspan="3" | '''ipcomp'''

+

| nexthdr

+

| Next header protocol (Upper layer protocol)

+

|-

+

| flags

+

| Flags

+

|-

+

| cfi

+

| Compression Parameter Index

+

|-

+

| '''icmp'''

+

| type

+

| icmp packet type

+

|-

+

| '''icmpv6'''

+

| type

+

| icmpv6 packet type

+

|-

+

|rowspan="12"|'''ct'''

+

|state

+

|State of the connection

+

|-

+

|direction

+

|Direction of the packet relative to the connection

+

|-

+

|status

+

|Status of the connection

+

|-

+

|mark

+

|Connection mark

+

|-

+

|expiration

+

|Connection expiration time

+

|-

+

|helper

+

|Helper associated with the connection

+

|-

+

|l3proto

+

|Layer 3 protocol of the connection

+

|-

+

|saddr

+

|Source address of the connection for the given direction

+

|-

+

|daddr

+

|Destination address of the connection for the given direction

+

|-

+

|protocol

+

|Layer 4 protocol of the connection for the given direction

+

|-

+

|proto-src

+

|Layer 4 protocol source for the given direction

+

|-

+

|proto-dst

+

|Layer 4 protocol destination for the given direction

+

|-

+

| rowspan="13" | '''meta'''

+

| length

+

| Length of the packet in bytes: ''meta length > 1000''

+

|-

+

| protocol

+

| ethertype protocol: ''meta protocol vlan''

+

|-

+

| priority

+

| TC packet priority

+

|-

+

| mark

+

| Packet mark

+

|-

+

| iif

+

| Input interface index

+

|-

+

| iifname

+

| Input interface name

+

|-

+

| iiftype

+

| Input interface type

+

|-

+

| oif

+

| Output interface index

+

|-

+

| oifname

+

| Output interface name

+

|-

+

| oiftype

+

| Output interface hardware type

+

|-

+

| skuid

+

| UID associated with originating socket

+

|-

+

| skgid

+

| GID associated with originating socket

+

|-

+

| rtclassid

+

| Routing realm

+

|-

+

|}

+

====Statements====

+

Statements represent the action to be performed when the rule matches. They exist in two kinds: Terminal statements, unconditionally terminate the evaluation of the current rules and non-terminal statements that either conditionally or never terminate the current rules. There can be an arbitrary amount of non-terminal statements, but there must be only a single terminal statement.

+

The terminal statements can be:

+

* '''accept''': Accept the packet and stop the ruleset evaluation.

+

* '''drop''': Drop the packet and stop the ruleset evaluation.

+

* '''reject''': Reject the packet with an icmp message

+

* '''queue''': Queue the packet to userspace and stop the ruleset evaluation.

+

* '''continue''':

+

* '''return''': Return from the current chain and continue at the next rule of the last chain. In a base chain it is equivalent to accept

+

* '''jump <chain>''': Continue at the first rule of <chain>. It will continue at the next rule after a return statement is issued

+

* '''goto <chain>''': Similar to jump, but after the new chain the evaluation will continue at the last chain instead of the one containing the goto statement

−

The '''amd64-bulldozer''' subarch supports the [[Wikipedia:Bulldozer (microarchitecture)|AMD bulldozer microarchitecture]] CPUs, which were released from late 2011 through the first quarter of 2012 as a replacement for the [[Wikipedia:AMD_10h|K10 microarchitecture]] CPUs.

+

== Installing nftables ==

−

Bulldozer desktop CPUs use the [[Wikipedia:Socket_AM3+|AM3+ socket]] and server CPUs use the [[Wikipedia:Socket_G34|G34 socket]].

+

=== Kernel ===

+

These kernel options must be set {{kernelop|title=Network support|desc= Networking options

The '''amd64-piledriver''' subarch supports the [[Wikipedia:Piledriver (microarchitecture)|AMD Piledriver microarchitecture]] produced by AMD from mid-2012 through 2015, which is the successor to the [[Wikipedia:Bulldozer (microarchitecture)|AMD bulldozer microarchitecture]].

+

== OpenRC configuration ==

−

Piledriver CPUs and APUs are available that use the [[Wikipedia:FM2 Socket|FM2 socket]]. Desktop Piledriver CPUs use the [[Wikipedia:Socket_AM3+|AM3+ socket]]. Server Piledriver CPUs use a variety of sockets, including [[Wikipedia:Socket_AM3+|AM3+]], [[Wikipedia:Socket_C32|C32]] and [[Wikipedia:Socket_G34|G34]].

Piledriver adds several new instructions over bulldozer, so AMD bulldozer systems cannot run amd64-piledriver-optimized stages. However, this subarch is instruction-compatible with its successor, the, so amd64-piledriver stages can run on amd64-steamroller systems, and vice versa.

−

=== amd64-steamroller ===

+

== Using nftables ==

+

All nftable commands are done with the nft ultility from {{Package|net-firewall/nftables}}.

+

===Tables===

+

====Creating tables====

+

The following command adds a table called filter for the ip(v4) layer

+

<console>

+

###i## nft add table ip filter

+

</console>

+

Likewise a table for arp can be created with

+

<console>

+

###i## nft add table arp filter

+

</console>

+

{{Note|The name "filter" used here is completly arbitrary. It could have any name}}

+

====Listing tables====

+

The following command lists all tables for the ip(v4) layer

+

<console>

+

###i## nft list tables ip

+

</console>

+

<pre>

+

table filter

+

</pre>

+

The contents of the table filter can be listed with:

+

<console>

+

###i## nft list table ip filter

+

</console>

+

<pre>

+

table ip filter {

+

chain input {

+

type filter hook input priority 0;

+

ct state established,related accept

+

iifname "lo" accept

+

ip protocol icmp accept

+

drop

+

}

+

}

+

</pre>

+

using -a with the nft command, it shows the handle of each rule. Handles are used for various operations on specific rules:

+

<console>

+

###i## nft -a list table ip filter

+

</console>

+

<pre>

+

table ip filter {

+

chain input {

+

type filter hook input priority 0;

+

ct state established,related accept # handle 2

+

iifname "lo" accept # handle 3

+

ip protocol icmp accept # handle 4

+

drop # handle 5

+

}

+

}

+

</pre>

−

The '''amd64-steamroller''' subarch supports the [[Wikipedia:Steamroller (microarchitecture)|AMD steamroller microarchitecture]], produced from early 2014. It is the successor to the [[Wikipedia:Piledriver (microarchitecture)|AMD Piledriver microarchitecture]].

+

====Deleting tables====

−

Steamroller APUs are available that use the [[Wikipedia:FM2+ Socket|FM2+ socket]] and [[Wikipedia:Socket_FP3|FP3 socket]] (mobile.)

+

The following command deletes the table called filter for the ip(v4) layer:

+

<console>

+

###i## nft delete table ip filter

+

</console>

+

===chains===

+

====Adding chains====

+

The following command adds a chain called input to the ip filter table and registered to the input hook with priority 0. It is of the type filter.

{{Note|If You're running this command from Bash you need to escape the semicolon}}

+

A non-base chain can be added by not specifying the chain configurations between the curly braces.

−

Desktop steamroller APUs include the [[Wikipedia:AMD_Accelerated_Processing_Unit#Steamroller_architecture_.282014.29:_Kaveri|A-Series with codename Kaveri]], such as the quad-core AMD A10-7850K APU. Steamroller APUs are also available in mobile versions. Server steamroller APUs will include the codename Berlin APUs, which are expected to be released some time in 2015.

+

====Removing chains====

+

The following command deletes the chain called input

+

<console>

+

###i## nft delete chain ip filter input

+

</console>

+

{{Note|Chains can only be deleted if there are no rules in them.}}

+

===rules===

+

====Adding rules====

+

The following command adds a rule to the chain called input, on the ip filter table, dropping all traffic to port 80:

+

<console>

+

###i## nft add rule ip filter input tcp dport 80 drop

+

</console>

+

====Deleting Rules====

+

To delete a rule, you first need to get the handle number of the rule. This can be done by using the -a flag on nft:

+

<console>

+

###i## nft rule ip filter input tcp dport 80 drop

+

</console>

+

<pre>

+

table ip filter {

+

chain input {

+

type filter hook input priority 0;

+

tcp dport http drop # handle 2

+

}

+

}

+

</pre>

+

It is then possible to delete the rule with:

+

<console>

+

###i## nft delete rule ip filter input handle 2

+

</console>

+

== Management ==

+

=== Backup ===

+

You can also backup your rules:

+

<console>

+

###i## echo "nft flush ruleset" > backup.nft

+

</console>

−

Amd64-steamroller subarches are instruction-compatible with amd64-piledriver, but add new instructions over amd64-bulldozer.

+

<console>

+

###i## nft list ruleset >> backup.nft

+

</console>

−

=== amd64-jaguar ===

+

=== Restoration ===

+

And load it atomically:

+

<console>

+

###i## nft -f backup.nft

+

</console>

−

The '''amd64-jaguar''' (also called AMD Family 16h) subarch supports the [[Wikipedia:Jaguar (microarchitecture)|AMD jaguar microarchitecture]], which is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the [[Wikipedia:Playstation 4|Playstation 4]] and [[Wikipedia:Xbox One|Xbox One]], which each use custom 8-core Jaguar APUs.

+

== OpenRC configuration ==

−

Socketed Jaguar APUs use the [[Wikipedia:AM1 Socket|AM1 socket]], and [[Wikipedia:Socket_FT3|FT3 socket]] for mobile devices. G-series [[Wikipedia:System_on_a_chip|"system on a chip" (SoC)]] APUs are available for non-socketed devices such as tablets and embedded system boards.

+

−

Desktop Jaguar APUs include the [[Wikipedia:List_of_AMD_accelerated_processing_unit_microprocessors#.22Kabini.22.2C_.22Temash.22_.282013.2C_28_nm.29|Kabini A-series APUs and Temash E-series APUs]], such as the Athlon 5150 and 5350 APUs, and Sempron 2650 and 3850.

+

Don't forget to add nftables service to startup:

+

<console>

+

###i## rc-update add nftables default

+

</console>

+

== Init script (firewall nftables like a iptables) ==

+

<pre>

+

#!/sbin/runscript

+

# Raphael Bastos aka coffnix #

+

# Init Script for Funtoo Linux #

+

##########################################

−

Amd64-jaguar subarches use the MOVBE instruction which is not available on amd64-bulldozer, amd64-piledriver or amd64-steamroller. They are thus not instruction-compatible with any of these subarches.

The '''atom_64''' (also known under the Intel code names Diamondville, Pineview, Cedarview and Centerton) subarch supports the [[Wikipedia:Bonnell_(microarchitecture)|Intel Bonnell microarchitecture]], representing a partial revival of the principles used in earlier Intel designs such as P5 and the i486, with the sole purpose of enhancing the performance per watt ratio. Successor to the [[Wikipedia:Stealey_(microprocessor)|Stealey_(microprocessor)]], which was derived from the [[Wikipedia:Pentium_M|Pentium M]], the Atom has been produced since 2008. Targeted at low-power devices, Atom processors can be found in a wide range of notebooks, tablets and small form-factor desktops and servers.

The Atom N2xx series Atom Diamondville models cannot support 64-bit operation, while the others only can "with a processor, chipset, BIOS" that all support [[Wikipedia:X86-64#Intel_64|Intel 64]]. This can lead to situations where non-Intel branded motherboards can have a 64-bit capable Atom processor which cannot run a 64-bit operating system. In this situation, you would need to use the [[subarches#atom_32|atom_32]] subarch.

Nftables

What is nftables?

nftables is the successor to iptables. It replaces the existing iptables, ip6tables, arptables and ebtables framework. It uses the Linux kernel and a new userspace utility called nft. nftables provides a compatibility layer for the ip(6)tables and framework.

Introduction

As with the iptables framework, nftables is build upon rules which specify the actions. These rules are attached to chains. A chain can contain a collection of rules and is registered into the netfilter hooks. Chains are stored inside tables. A table is specific for one of the layer 3 protocols. One of the main differences with iptables is that there are no predefined tables and chains anymore.

Tables

A table is nothing more than a container for your chains. With nftables there are no predefined tables (filter, raw, mangle...) anymore. You are free to recreate the iptables-like structure, but anything might do.
Currently there are 5 different families of tables:

ip: Used for IPv4 related chains;

ip6: Used for IPv6 related chains;

arp: Used for ARP related chains;

bridge: Used for bridging related chains;

inet: Mixed ipv4/ipv6 chains (kernel 3.14 and up).

It is not hard to recognize the old tables framework in these tables. The only new one is the inet table which is used for both IPv4 and IPv6 traffic. It should make firewalling for dual-stack hosts easier by combining the rules for IPv4 and IPv6.

Chains

Chains are used to group together rules. As with the tables, nftables does not have any predefined chains. Chains are grouped in base and non-base types. Base chains are registered in one of the netfilter hooks. A base chain has a hook its registered with, a type and a priority. Non-base chains are not attached to a hook and they don't see any traffic by default. They can be used to arrange a rule-set in a tree of chains.
There are currently three types of chains:

filter: for filtering packets

route: for rerouting packets

nat: for performing Network Address Translation. Only the first packet of a flow hits this chain, making it impossible to use it for filtering.

The hooks that can be used are:

prerouting: This is before the routing decision, all packets entering the machine hits this chain

input: All packets for the local system hits this hook

forward: Packets not for the local system, those that need to be forwarded hits this hook

output: Packets that originate from the local system pass this hook

postrouting: This hook is after the routing decision, all packets leaving the machine hits this chain

Note

The ARP address family only supports the input and output hook

Note

The bridge address family only seems to supports the input, forward and output hook

Priorities

Note

Priorities do not currently appear to have any effect on which chain sees packets first.

Note

Since the priority seems to be an unsigned integer, negative priorities will be converted into very high priorities.

Rules

Rules specify which action has to be taken for which packets. Rules are attached to chains. Each rule can has an expression to match packets with and one or multiple actions when matching. Main differences with iptables is that it is possible to specify multiple actions and that by default counters are off. It must be specified explicitly in rules if you want packet- and byte-counters for a rule.
Each rule has a unique handle number by which it can be distinguished.
The following matches are available:

ip: IP protocol

ip6: IPv6 protocol

tcp: TCP protocol

udp: UDP protocol

udplite: UDP-lite protocol

sctp: SCTP protocol

dccp: DCCP protocol

ah: Authentication headers

esp: Encrypted security payload headers

ipcomp: IPcomp headers

icmp: icmp protocol

icmpv6: icmpv6 protocol

ct: Connection tracking

meta: meta properties such as interfaces

Matches

Match

Arguments

Description/Example

ip

version

Ip Header version

hdrlength

IP header length

tos

Type of Service

length

Total packet length

id

IP ID

frag-off

Fragmentation offset

ttl

Time to live

protocol

Upper layer protocol

checksum

IP header checksum

saddr

Source address

daddr

Destination address

ip6

version

IP header version

priority

flowlabel

Flow label

length

Payload length

nexthdr

Next header type (Upper layer protocol number)

hoplimit

Hop limit

saddr

Source Address

daddr

Destination Address

tcp

sport

Source port

dport

Destination port

sequence

Sequence number

ackseq

Acknowledgement number

doff

Data offset

flags

TCP flags

window

Window

checksum

Checksum

urgptr

Urgent pointer

udp

sport

Source port

dport

destination port

length

Total packet length

checksum

Checksum

udplite

sport

Source port

dport

destination port

cscov

Checksum coverage

checksum

Checksum

sctp

sport

Source port

dport

destination port

vtag

Verification tag

checksum

Checksum

dccp

sport

Source port

dport

destination port

ah

nexthdr

Next header protocol (Upper layer protocol)

hdrlength

AH header length

spi

Security Parameter Index

sequence

Sequence Number

esp

spi

Security Parameter Index

sequence

Sequence Number

ipcomp

nexthdr

Next header protocol (Upper layer protocol)

flags

Flags

cfi

Compression Parameter Index

icmp

type

icmp packet type

icmpv6

type

icmpv6 packet type

ct

state

State of the connection

direction

Direction of the packet relative to the connection

status

Status of the connection

mark

Connection mark

expiration

Connection expiration time

helper

Helper associated with the connection

l3proto

Layer 3 protocol of the connection

saddr

Source address of the connection for the given direction

daddr

Destination address of the connection for the given direction

protocol

Layer 4 protocol of the connection for the given direction

proto-src

Layer 4 protocol source for the given direction

proto-dst

Layer 4 protocol destination for the given direction

meta

length

Length of the packet in bytes: meta length > 1000

protocol

ethertype protocol: meta protocol vlan

priority

TC packet priority

mark

Packet mark

iif

Input interface index

iifname

Input interface name

iiftype

Input interface type

oif

Output interface index

oifname

Output interface name

oiftype

Output interface hardware type

skuid

UID associated with originating socket

skgid

GID associated with originating socket

rtclassid

Routing realm

Statements

Statements represent the action to be performed when the rule matches. They exist in two kinds: Terminal statements, unconditionally terminate the evaluation of the current rules and non-terminal statements that either conditionally or never terminate the current rules. There can be an arbitrary amount of non-terminal statements, but there must be only a single terminal statement.
The terminal statements can be:

accept: Accept the packet and stop the ruleset evaluation.

drop: Drop the packet and stop the ruleset evaluation.

reject: Reject the packet with an icmp message

queue: Queue the packet to userspace and stop the ruleset evaluation.

continue:

return: Return from the current chain and continue at the next rule of the last chain. In a base chain it is equivalent to accept

jump <chain>: Continue at the first rule of <chain>. It will continue at the next rule after a return statement is issued

goto <chain>: Similar to jump, but after the new chain the evaluation will continue at the last chain instead of the one containing the goto statement