tree bb4eda4785484cc4be59c16b36fe51d1e91c62ce
parent b1b24aec274728c5ceb914fc4511828432c3fbed
author Adel Belhouane <bugs.a.b@free.fr> 1564125877 +0200
committer Florian Westphal <fw@strlen.de> 1564360496 +0200

restore legacy behaviour of iptables-restore when rules start with -4/-6

v2: moved examples to testcase files

Legacy implementation of iptables-restore / ip6tables-restore allowed
to insert a -4 or -6 option at start of a rule line to ignore it if not
matching the command's protocol. This allowed to mix specific ipv4 and
ipv6 rules in a single file, as still described in iptables 1.8.3's man
page in options -4 and -6. The implementation over nftables doesn't behave
correctly in this case: iptables-nft-restore accepts both -4 or -6 lines
and ip6tables-nft-restore throws an error on -4.

There's a distribution bug report mentioning this problem:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925343

Restore the legacy behaviour:
- let do_parse() return and thus not add a command in those restore
  special cases
- let do_commandx() ignore CMD_NONE instead of bailing out

I didn't attempt to fix all minor anomalies, but just to fix the
regression. For example in the line below, iptables should throw an error
instead of accepting -6 and then adding it as ipv4:

% iptables-nft -6 -A INPUT -p tcp -j ACCEPT

Signed-off-by: Adel Belhouane <bugs.a.b@free.fr>
Signed-off-by: Florian Westphal <fw@strlen.de>