| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pablo reported test failures because the order of returned set entries
is not deterministic.
This sorts set elements before comparision.
Patrick suggested to move ordering into libnftnl (since we could f.e.
also get duplicate entries due to how netlink dumps work), but thats a bit
more work. Hence this quick workaround.
Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
| |
Since 357d8cfcceb2 ("tests: use the src/nft binary instead of $PATH one"), the
tests fail if you try to run them if you are not under the root directory of
the nftables repository.
Display an error so I don't forget I have to do it like this.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
| |
... so one doesn't need to install new binary into $PATH (or
change PATH... ) during development.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compare netlink instructions generated by given nft command line
with recorded version.
Example: udp dport 80 accept in ip family should look like
ip test-ip4 input
[ payload load 1b @ network header + 9 => reg 1 ]
[ cmp eq reg 1 0x00000011 ]
[ payload load 2b @ transport header + 2 => reg 1 ]
[ cmp eq reg 1 0x00005000 ]
[ immediate reg 0 accept ]
This is stored in udp.t.payload.ip
Other suffixes:
.payload.ip6
.payload.inet
.payload ('any')
The test script first looks for 'testname.t.payload.$family', if that
doesn't exist 'testname.t.payload' is used.
This allows for family independent test (e.g. meta), where we don't
expect/have any family specific expressions.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... 2001:838:35f:1::-2001:838:35f:2:: :80-100' mismatches
... 2001:838:35f:1::-2001:838:35f:2:::80-100'
nft accepts both, so just alter test to not complain.
Also, fix test script to display the expected output rather than
the input. Otherwise, a rule like
some_input;ok;expected_output
may display nonsensical message like
warning: some_input mismatches some_input
This also fixes the icmpv6 test accordingly, nft displays ranges
correctly.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
|
|
|
|
| |
Consolidate print_err() and print_warning() into print_msg() to reduce code
duplication.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
| |
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
|
|
|
|
|
|
|
| |
nft now prints the default chain policy, consider this when parsing
the output to find mismatches.
Signed-off-by: Arturo Borrero <arturo.borrero.glez@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
| |
Avoid copy&paste coding style pattern by simplifying the code that
handles the `-e' option that allows us to run known broken tests.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
| |
Always increment the test file counter for each test file in the list.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
| |
If the output string doesn't match the input, indicate that the output
mismatches instead of the misleading "Listing is broken".
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
| |
Not useful, they just bloat the nft-tests.py output.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the script is run with the -e option, the output messages show an
unnecessary white-space. This path fixes this mistake.
sudo ./nft-test.py -e
[...] "line 34: nft add rule -nnn arp test-arp input arp plen != {33-55} " [...]
^^^^
Signed-off-by: Ana Rey <anarey@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Here, the automated regression testing for nftables and some test
files.
This script checks that the rule input and output of nft matches.
More details here below.
A) What is this testing?
This script tests two different paths:
* The rule input from the command-line. This checks the different steps
from the command line to the kernel. This includes the parsing,
evaluation and netlink generation steps.
* The output listing that is obtained from the kernel. This checks the
different steps from the kernel to the command line: The netlink
message parsing, postprocess and textify steps to display the rule
listing.
As a final step, this script compares that the rule that is added can
be listed by nft.
B) What options are available?
The script offers the following options:
* Execute test files:
./nft-test.py # Run all test files
./nft-test.py path/file.t # Run this test file
If there is a problem, it shows the differences between the rule that
is added and the rule that is listed by nft.
In case you hit an error, the script doesn't keep testing for more
families. Unless you specify the --force-family option.
* Execute broken tests:
./nft-test.sh -e
This runs tests for rules that need a fix: This mode runs the lines that
that start with a "-" symbol.
* Debugging:
./nft-test.sh -d
This shows all the commands that the script executes, so you can watch
its internal behaviour.
* Keep testing all families on error.
./nft-test.sh -f
Don't stop testing for more families in case of error.
C) What is the structure of the test file?
A test file contains a set of rules that are added in the system.
Here, an example of a test file:
*ip;test-ipv4 # line 1
*ip6;test-ipv6 # line 2
*inet;test-inet # line 3
:input;type filter hook input priority 0 # line 4
ah hdrlength != 11-23;ok;ah hdrlength < 11 ah hdrlength > 23 # line 5
- tcp dport != {22-25} # line 6
!set1 ipv4_addr;ok # line 7
?set1 192.168.3.8 192.168.3.9;ok # line 8
# This is a commented-line. # line 9
Line 1 defines a table. The name of the table is 'test-ip' and the
family is ip. Lines 2 and 3 defines more tables for different families
so the rules in this test file are also tested there.
Line 4 defines the chain. The name of this chain is "input". The type is
"filter", the hook is "input" and the priority is 0.
Line 5 defines the rule, the ";" character is used as separator of several
parts:
* Part 1: "ah hdrlength != 11-23" is the rule to check.
* Part 2: "ok" is the result expected with the execute of this rule.
* Part 3: "ah hdrlength < 11 ah hdrlength > 23". This is the expected
output. You can leave this empty if the output is the same as the
input.
Line 6 is a marked line. This means that this rule is tested if
'-e' is passed as argument to nft-test.py.
Line 7 adds a new set. The name of this set is "set1" and the type
of this set is "ipv4_add".
Line 8 adds two elements into the 'set1' set: "192.168.3.8" and
"192.168.3.9". A whitespace separates the elements of the set.
Line 9 uses the "#" symbol that means that this line is commented out.
D) The test folders
The test files are divided in several directories: ip, ip6, inet, arp,
bridge and any.
* "ip" folder contains the test files that are executed in ip and inet
table.
* "ip" folder contains the test files that are executed in ip6 and inet
table.
* "inet" folder contains the test files that are executed in the ip, ip6
and inet table.
* "arp" folder contains the test files that are executed in the arp
table.
* "bridge" folder: Here are the test files are executed in bridge
tables.
* "any" folder: Here are the test files are executed in ip, ip6, inet,
arp and bridge tables.
E) Meaning of messages:
* A warning message means the rule input and output of nft mismatches.
* An error message means the nft-tool shows an error when we add it or
the listing is broken after the rule is added.
Signed-off-by: Ana Rey <anarey@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|