Arushi Singhal [Sat, 9 Jun 2018 17:34:27 +0000 (23:04 +0530)]
iptables: tests: shell: add shell test-suite
To run the test suite (as root):
% cd iptables/tests/shell
% ./run-tests.sh
Test files are executables files with the pattern <<name_N>> , where
N is the expected return code of the executable. Since they are
located with `find', test-files can be spreaded in any sub-directories.
You can turn on a verbose execution by calling:
% ./run-tests.sh -v
Before each call to the test-files, `kernel_cleanup' will be called.
Also, test-files will receive the environment variable $IPTABLES which
contains the path to the iptables binary being tested.
You can pass an arbitrary $IPTABLES value as well:
% IPTABLES=/../../xtables-multi iptables ./run-tests.sh
Signed-off-by: Arushi Singhal <arushisinghal19971997@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Check for nft_insert_rule, since nft_add_rule is never set via nft_fn.
Moreover, generalize ELOOP error since there is only one single location
in the kernel code where we can hit this.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Perform incremental tracking on rule cache updates, instead of flushing
and resynchronizing with the kernel over and over again.
Note that there is no need to call flush_rule_cache() from
nft_rule_delete() and nft_rule_delete_num(), since __nft_rule_del()
already deletes the rule from the list.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
So we don't have to dump the chain cache content over and over again.
Moreover, perform incremental updates on the chain cache to add and to
delete non-base chains.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Florian Westphal [Mon, 28 May 2018 20:17:39 +0000 (22:17 +0200)]
xtables-compat: append all errors into single line
iptables-restore < /tmp/bogus
iptables-restore v1.6.2: iptables-restore:
line 49: RULE_APPEND failed (No such file or directory): rule in chain FOOBAR
line 2023: RULE_APPEND failed (Invalid argument): rule in chain TESTSNAT
This is a followup commit to 437746c7b528f ("xtables: extended error reporting").
Florian Westphal [Thu, 24 May 2018 15:57:34 +0000 (17:57 +0200)]
xtables-compat: remove nft_is_ruleset_compatible
Use nft_is_table_compatible instead as only helper to a 'skip' decision.
Custom tables, tables that have extra base chains that iptables
syntax doesn't allow or rules that have special constructs line nftables
set lookups or verdict maps are not listed, but a message is provided
to show that such table exists.
No translation. The kernel match will alter packet type
(meta set pkttype), but also replace dst mac with the bridges' mac address,
however nft currently doesn't allow to retrieve this at runtime.
This always uses xtables_ipv4 (which is same as _ipv6).
Pass the correct skeleton instead, this is needed to handle ebtables
correctly from xt-translate, as it doesn't use ip/ip6 tables.
extensions: libxt_CONNMARK: incorrect translation after v2
src: iptables-translate -t mangle -A PREROUTING -j CONNMARK --set-mark 0
exp: nft add rule ip mangle PREROUTING counter ct mark set 0x0
res: nft add rule ip mangle PREROUTING counter ct mark set ct mark and 0x0
Fixes: db7b4e0de960 ("extensions: libxt_CONNMARK: Support bit-shifting for --restore,set and save-mark") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Jack Ma [Tue, 24 Apr 2018 02:58:57 +0000 (14:58 +1200)]
extensions: libxt_CONNMARK: Support bit-shifting for --restore,set and save-mark
This patch adds a new feature to iptables that allow bitshifting for
--restore,set and save-mark operations. This allows existing logic
operators (and, or and xor) and mask to co-operate with new bitshift
operations.
The intention is to provide uses with more fexible uses of skb->mark
and ct->mark. For example, users can save extra bits in skb->mark:
skb->mark = ct->mark << 8;
Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Jack Ma <jack.ma@alliedtelesis.co.nz> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
xtables-compat-restore: flush user-defined chains with -n
-n still flushes user-defined chains and its content, the following snippet:
iptables-compat -N FOO
iptables-compat -I INPUT
iptables-compat -I FOO
iptables-compat -I FOO
iptables-compat-save > A
iptables-compat-restore < A
iptables-compat -N BAR
iptables-compat -A BAR
iptables-compat-restore -n < A
results in:
iptables-compat-save
# Generated by xtables-save v1.6.2 on Mon May 7 17:18:44 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:BAR - [0:0]
:FOO - [0:0]
-A INPUT
-A INPUT
-A BAR
-A FOO
-A FOO
COMMIT
# Completed on Mon May 7 17:18:44 2018
Still, user-defined chains that are not re-defined, such as BAR, are
left in place.
Reported-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Thierry Du Tre [Tue, 3 Apr 2018 16:39:22 +0000 (18:39 +0200)]
extensions: libipt_DNAT: support shifted portmap ranges
This is a proposal patch for iptables DNAT extension to support shifted portmap
ranges. It is related to the kernel patch proposed in earlier message '[PATCH
v5] netfilter : add NAT support for shifted portmap ranges'.
A new struct nf_nat_range2 was added as extension for existing struct
nf_nat_range and is used by new revisions (2) for the DNAT target. Current DNAT
revisions for Ipv4 (rev 0) and IPv6 (rev 1) are kept so functionality with
older kernels is not impacted.
The syntax for shifted portmaps uses an extra value in '--to-destination' for
setting the base port which determines the offset in the redirect port range
for incoming connections. i.e. : iptables -t nat -A zone_wan_prerouting -p tcp
-m tcp --dport 5000:5100 -j DNAT --to-destination '192.168.1.2:2000-2100/5000'
The base port value is totally optional, so current behavior is not impacted in
any way. The use of slash '/' as separator is an arbitrary choice, all other
suggestions are valid of course (original proposal used semicolon but this was
not practical for commandline use) Another approach using an additional option
seems also possible (i.e. '--base-port 5000'). However, that would mean more
parsing logic with extra lines of code and thus increased risk for regression.
Signed-off-by: Thierry Du Tre <thierry@dtsystems.be> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Serhey Popovych [Wed, 7 Mar 2018 09:10:43 +0000 (11:10 +0200)]
xtables: Fix rules print/save after iptables update
Updating iptables from 1.4.x to 1.6.x brokes rules print/save output
and causes rules load after reboot to fail. Here is example from
iptables-save(8) output after update:
-A CHAIN1 -m set [unsupported revision] -j DROP
-A CHAIN1 -m set [unsupported revision] -j DROP
Similar output could be obtained via iptables -L CHAIN1. While issue
reproduced with xt_set match it is not specific to any match or
target module: it is related on how xtables handles revisions.
In this particular case we have following situation:
1) Kernel supports revisions from 1 to 4.
2) Rules configured with iptables 1.4.x supporting only
revisions from 1 to 3. Choosen highest possible revision 3.
3) Rules printed/saved with iptables 1.6.x supporting revisions
from 1 to 4.
4) Xtables registers matches/targets with highest supported
revision by the kernel. This is 4 in our case after update to
iptables 1.6.x.
5) When printing/saving kernel submits match/target with revision
it is configured (3), while iptables thinks that rules configured
with highest supported (4). That's causes revision mismatch in
during print and "[unsupported revision]" output.
To fix this issue we now store all supported by kernel and xtables
revisions in xt_matches/xt_targets list sorted in descending order.
Introduce helper routines to find match/target with given revision
and use them to find right revision to print submitted by kernel
entry.
Serhey Popovych [Wed, 7 Mar 2018 09:10:42 +0000 (11:10 +0200)]
xtables: Register all match/target revisions supported by us and kernel
Keep the order of matches by appending them; keep order between
revisions of same match from most to least recent. All of this
keeps xtables_find_match() happy to find most recent supported
by kernel revision in the given order.
Apply the same for targets, except prepend targets; order between
revisions preserved too.
All this needed to fix nasty bug related to iptables package update
and broken print/save output.
After this change all supported revisions of match/target stored
in corresponding list with following pattern:
Where new [m]atches added to the list tail and new [t]argets added
to the list head to preserve previous behaviour. Multiple revisions
of single match/target type are grouped together and sorted in
descending order. Both this ensures xtables_find_match() and
xtables_find_target() behaviour remains the same after change: find
highest supported match/target revision given by it's name.
Serhey Popovych [Thu, 1 Mar 2018 11:03:10 +0000 (13:03 +0200)]
extensions: Initialize linear mapping of symbols in _init() of extension
libxt_devgroup and libipt_realm currently unable to display symbolic
names in save/print commands because linear mapping is not initialized.
It looks bit confusing as linear mapping initialization is done in init()
of extension, which is expected to be called before any other function of
extension.
However init is called only when '-m' option specified on command line,
that is true only for insert, append, replace and destroy iptables
commands.
Move initialization to extension _init() function before calling
any function in extension.
Its not supported anymore as of 4.13, and it did not work
before this either (arp packets cannot be routed).
This unbreaks arptables-compat -- without this fix kernel rejects the
incoming ruleset skeleton.
filtering forwarded arp packets on a bridge can be done either via
'netdev' or 'bridge' families.
projects / thirdparty / iptables.git / log
