Hi Adel, On Wed, Jul 24, 2019 at 10:13:02PM +0200, Adel Belhouane wrote: > 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. Thanks for catching this. Seems like at some point the intention was to have a common 'xtables' command and pass -4/-6 parameters to toggle between iptables and ip6tables operation. Pablo, is this still relevant, or can we just get rid of it altogether? > Example with the file /tmp/rules: > > *filter > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > -4 -A INPUT -p icmp -j ACCEPT > -6 -A INPUT -p ipv6-icmp -j ACCEPT > COMMIT Would you mind creating a testcase in iptables/tests/shell? I guess testcases/ipt-restore is suitable, please have a look at 0003-restore-ordering_0 in that directory for an illustration of how we usually check results of *-restore calls. [...] > It doesn't attempt to fix all minor anomalies, but just to fix the regression. > For example the line below should throw an error according to the man page > (and does in the legacy version), but doesn't in the nft version: > > % iptables -6 -A INPUT -p tcp -j ACCEPT On my testing VM this rule ends up in table ip filter, so this seems to not even work as intended. > Signed-off-by: Adel Belhouane <bugs.a.b@xxxxxxx> Acked-by: Phil Sutter <phil@xxxxxx>
