On Monday 2015-08-10 14:04, Pablo Neira Ayuso wrote: >> I oppose that idempotent expressions in rules, implicit or explicit, >> shall lead to output when the ruleset is read back. A rule like >> >> -A INPUT -m policy --dir in >> >> should not, by default, cause `iptables -S` to output a >> rule with terms essentially irrelevant to the human reader. >> >> -A INPUT -m policy --dir in --reqid 0:4294967295 [...] > >The point is that this has been broken for two years, chances that >users have fixed this in the ruleset without reporting is high, so >restoring the old behaviour may break things again for them. Users that went that route have nothing to worry. If their input ruleset explicitly specified some --reqid x:y, then they will get the desired x <= reqid <= y test no matter the iptables version. >That's why I'm insisting on the fact that switching to a less obscure >behaviour is a good idea in the very specific case of 'ah' since they >can easily detect that things have change by diffing the new and old >iptables-save output. Mind you, diffing is exactly how this bug _was_ discovered. A modified print/save function would have done _nothing_ to prevent the bug. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html