| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Followup patch will replace the { 1.2.3.4 } with single
cmp, so this will cause an error when the netlink dump gets
compared.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nft can load but not list this:
table inet filter {
chain input {
ct original ip daddr {1.2.3.4} accept
}
}
Problem is that the ct template length is 0, so we believe the right hand
side is a concatenation because left->len < set->key->len is true.
nft then calls abort() during concatenation parsing.
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1222
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These keys are available since kernel >= 4.17.
You can still use NFT_CT_{SRC,DST}, however, you need to specify 'meta
protocol' in first place to provide layer 3 context.
Note that NFT_CT_{SRC,DST} are broken with set, maps and concatenations.
This patch is implicitly fixing these cases.
If your kernel is < 4.17, you can still use address matching via
explicit meta nfproto:
meta nfproto ipv4 ct original saddr 1.2.3.4
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
| |
use 'ip saddr', 'ip6 saddr', etc.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
any/ct.t: ERROR: line 94: src/nft add rule --debug=netlink ip6
test-ip6 output meta nfproto ipv4 ct original saddr 1.2.3.4: This rule should not have failed.
Actually, this failure is "ok; we can't find upper layer protocol
in this case, but even if we'd "fix" this it is still non-sensical,
meta nfproto ipv4, but family is ipv6 --> rule would never match.
First move this to an inet-specific test.
A followup patch will reject meta nfproto for all families except inet.
Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
