| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think flags should be displayed in hexadecimal and should be handled as a
bitmask.
inet/comp.t: WARNING: line: 15: 'nft add rule ip test-ip4 input comp flags 0x00': 'comp flags 0x00' mismatches 'comp flags 0'
inet/comp.t: WARNING: line: 16: 'nft add rule ip test-ip4 input comp flags != 0x23': 'comp flags != 0x23' mismatches 'comp flags != 35'
inet/comp.t: WARNING: line: 17: 'nft add rule ip test-ip4 input comp flags 0x33-0x45': 'comp flags 0x33-0x45' mismatches 'comp flags 51-69'
inet/comp.t: WARNING: line: 18: 'nft add rule ip test-ip4 input comp flags != 0x33-0x45': 'comp flags != 0x33-0x45' mismatches 'comp flags != 51-69'
inet/comp.t: WARNING: line: 19: 'nft add rule ip test-ip4 input comp flags {0x33, 0x55, 0x67, 0x88}': 'comp flags {0x33, 0x55, 0x67, 0x88}' mismatches 'comp flags { 103, 85, 51, 136}'
inet/comp.t: WARNING: line: 21: 'nft add rule ip test-ip4 input comp flags { 0x33-0x55}': 'comp flags { 0x33-0x55}' mismatches 'comp flags { 51-85}'
rfc3173 says that this is unused for future use though.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix lots of warnings, mostly related to the listing of ranges in many of the
tests that we have, eg.
any/meta.t: WARNING: line: 30: 'nft add rule ip test-ip4 input meta l4proto 33-45': 'meta l4proto 33-45' mismatches 'meta l4proto 33-45'
any/meta.t: WARNING: line: 31: 'nft add rule ip test-ip4 input meta l4proto != 33-45': 'meta l4proto != 33-45' mismatches 'meta l4proto != 33-45'
any/meta.t: WARNING: line: 99: 'nft add rule ip test-ip4 input meta skuid 3001-3005 accept': 'meta skuid 3001-3005 accept' mismatches 'skuid 3001-3005 accept'
any/meta.t: WARNING: line: 100: 'nft add rule ip test-ip4 input meta skuid != 2001-2005 accept': 'meta skuid != 2001-2005 accept' mismatches 'skuid != 2001-2005 accept'
any/meta.t: WARNING: line: 111: 'nft add rule ip test-ip4 input meta skgid 2001-2005 accept': 'meta skgid 2001-2005 accept' mismatches 'skgid 2001-2005 accept'
any/meta.t: WARNING: line: 112: 'nft add rule ip test-ip4 input meta skgid != 2001-2005 accept': 'meta skgid != 2001-2005 accept' mismatches 'skgid != 2001-2005 accept'
any/meta.t: WARNING: line: 156: 'nft add rule ip test-ip4 input meta cpu 1-3': 'meta cpu 1-3' mismatches 'cpu 1-3'
any/meta.t: WARNING: line: 158: 'nft add rule ip test-ip4 input meta cpu != 1-2': 'meta cpu != 1-2' mismatches 'cpu != 1-2'
any/meta.t: WARNING: line: 187: 'nft add rule ip test-ip4 input meta cgroup 0x100001 - 0x100003': 'meta cgroup 0x100001 - 0x100003' mismatches 'cgroup 1048577-1048579'
...
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inet tables
In rules like:
nft add rule inet filter input reject
or
nft add rule bridge filter input reject
we use icmpx to reject it. But if we have network context, we also use type of
reject. With this patch, we check the network context. If we don't have context,
we still use icmpx. However, if we have rules with network context like:
nft add rule inet meta nfproto ipv4 reject
or
nft add rule bridge ether type ipv6 reject
We are going to use icmp or icmpv6 to reject it taking into account the network
context.
Signed-off-by: Alvaro Neira Ayuso <alvaroneay@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
|
|
|
| |
Signed-off-by: Alvaro Neira Ayuso <alvaroneay@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
"inet" folder contains the test files that are executed in ipv4, ipv6
and inet family of tables.
These test files are executed with nft-tests.py
Signed-off-by: Ana Rey <anarey@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|