Instead of adding a second, compatible rule-representation to kernel for consumption by older user space, follow a much simpler route by implementing a compat-mode into current *tables-nft which avoids any of the later internal changes which may prevent an old iptables-nft from parsing a kernel's rule correctly. Patch 1 is just prep work, patch 2 adds the core logic, patch 3 exposes it to CLI and patch 4 finally adds some testing. This should resolve nfbz#1632[1], albeit requiring adjustments in how users call iptables. [1] https://bugzilla.netfilter.org/show_bug.cgi?id=1632 Phil Sutter (4): nft: Pass nft_handle to add_{target,action}() nft: Introduce and use bool nft_handle::compat Add --compat option to *tables-nft and *-nft-restore commands tests: Test compat mode iptables-test.py | 19 ++++-- iptables/nft-arp.c | 2 +- iptables/nft-bridge.c | 9 +-- iptables/nft-ipv4.c | 2 +- iptables/nft-ipv6.c | 2 +- iptables/nft-shared.c | 2 +- iptables/nft.c | 15 +++-- iptables/nft.h | 5 +- .../testcases/nft-only/0011-compat-mode_0 | 61 +++++++++++++++++++ iptables/xshared.c | 7 ++- iptables/xshared.h | 1 + iptables/xtables-arp.c | 1 + iptables/xtables-eb.c | 7 ++- iptables/xtables-restore.c | 17 +++++- iptables/xtables.c | 2 + 15 files changed, 129 insertions(+), 23 deletions(-) create mode 100755 iptables/tests/shell/testcases/nft-only/0011-compat-mode_0 -- 2.40.0
