| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are evaluating a `reject` statement in the `inet` family, we may
have `ether` and `ip` or `ip6` as the L2 and L3 protocols in the
evaluation context:
table inet filter {
chain input {
type filter hook input priority filter;
ether saddr aa:bb:cc:dd:ee:ff ip daddr 192.168.0.1 reject
}
}
Since no `reject` option is given, nft attempts to infer one and fails:
BUG: unsupported familynft: evaluate.c:2766:stmt_evaluate_reject_inet_family: Assertion `0' failed.
Aborted
The reason it fails is that the ethernet protocol numbers for IPv4 and
IPv6 (`ETH_P_IP` and `ETH_P_IPV6`) do not match `NFPROTO_IPV4` and
`NFPROTO_IPV6`. Add support for the ethernet protocol numbers.
Replace the current `BUG("unsupported family")` error message with
something more informative that tells the user to provide an explicit
reject option.
Add a Python test case.
Fixes: 5fdd0b6a0600 ("nft: complete reject support")
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001360
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The kernel already assumes that that ICMP type to reject a packet is
destination-unreachable, hence the user specifies the *ICMP code*.
Simplify the syntax to:
... reject with icmp port-unreachable
this removes the 'type' keyword before the ICMP code to reject the
packet with.
IIRC, the original intention is to leave room for future extensions that
allow to specify both the ICMP type and the ICMP code, this is however
not possible with the current inconsistent syntax.
Update manpages which also refer to ICMP type.
Adjust tests/py to the new syntax.
Fixes: 5fdd0b6a0600 ("nft: complete reject support")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Extend parser to accept a numeric icmp code, instead of bailing out:
# nft add rule inet filter input reject with icmpx type 3
Error: syntax error, unexpected number, expecting string
add rule inet filter input reject with icmpx type 3
^
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1555
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just basic housekeeping:
- Remove duplicate tests in any of the *.t files
- Remove explicit output if equal to command itself in *.t files
- Remove duplicate payload records in any of the *.t.payload* files
- Remove stale payload records (for which no commands exist in the
respective *.t file
- Remove duplicate/stale entries in any of the *.t.json files
In some cases, tests were added instead of removing a stale payload
record if it fit nicely into the sequence of tests.
Signed-off-by: Phil Sutter <phil@nwl.cc>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 3e6ab2b335142 added restraints on reject types for bridge and
inet families but aparently those were too strict: If a rule in e.g.
inet family contained a match which introduced a protocol dependency,
icmpx type rejects were disallowed for no obvious reason.
Allow icmpx type rejects in inet family regardless of protocol
dependency since we either have IPv4 or IPv6 traffic in there and for
both icmpx is fine.
Merge restraints in bridge family with those for TCP reset since it
already does what is needed, namely checking that ether proto is either
IPv4 or IPv6.
Fixes: 3e6ab2b335142 ("evaluate: reject: check in bridge and inet the network context in reject")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
| |
|
|
|
|
|
| |
... to avoid resetting e.g. the ssh session to the vm that runs
nft-test.py.
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
|
Rearrange the directory to obtain a better organization of files and
tests-suites.
We end with a tree like this:
tests
|
.--- py
.--- shell
.--- files
This was suggested by Pablo.
Signed-off-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
