Hi Pablo, On Thu, Oct 14, 2021 at 10:56:09PM +0200, Pablo Neira Ayuso wrote: > On Thu, Sep 30, 2021 at 04:04:02PM +0200, Phil Sutter wrote: > > Commandline parsing was widely identical with iptables and ip6tables. > > This series adds the necessary code-changes to unify the parsers into a > > common one. > > > > Changes since v1: > > - Fix patch 12, the parser has to check existence of proto_parse > > callback before dereferencing it. Otherwise arptables-nft segfaults if > > '-p' option is given. > > LGTM. Thanks for your review! > > - Patches 13-17 add all the arptables quirks to restore compatibility > > with arptables-legacy. I didn't consider them important enough to push > > them unless someone complains. Yet breaking existing scripts is bad > > indeed. Please consider them RFC: If you consider (one of) them not > > important, please NACk and I will drop them before pushing. > > For patch 13-16, you could display a warning for people to fix their > scripts, so this particular (strange) behaviour in some cases can be > dropped (at least, 13-15 look like left-over/bugs). For the > check_inverse logic, I'd suggest to display a warning too, this is > what it was done in iptables time ago to address this inconsistency. I wonder how likely it is for someone to rely upon the behaviour. I can imagine a script passing an empty interface name and expecting the argument to be ignored (patch 13). Though what are the odds someone actually calls arptables with '-m something' (patch 14) or a bogus table name (patch 15)? > I'd probably keep back patch 17/17, the max chain name length was > reduced by when the revision field was introduced and this resulted in > no issue being reported. If that's OK with you, I would turn the empty interface name error into a warning for arptables-nft, reintroduce the warning for intrapositioned negations and drop the remaining quirks as they are likely hiding a bug. Cheers, Phil
