On Sun, Jan 16, 2022 at 08:08:15PM +0100, Florian Westphal wrote: > Jeremy Sowden <jeremy@xxxxxxxxxx> wrote: > > On 2021-10-01, at 18:41:34 +0100, Jeremy Sowden wrote: > > > nftables supports 128-character prefixes for nflog whereas legacy > > > iptables only supports 64 characters. This patch series converts > > > iptables-nft to use the nft back-end in order to take advantage of the > > > longer prefixes. > > > > > > * Patches 1-5 implement the conversion and update some related Python > > > unit-tests. > > > * Patch 6 fixes an minor bug in the output of nflog prefixes. > > > * Patch 7 contains a couple of libtool updates. > > > * Patch 8 fixes some typo's. > > > > I note that Florian merged the first patch in this series recently. > > Yes, because it was a cleanup not directly related to the rest. > I've now applied the last patch as well for the same reason. > > > Feedback on the rest of it would be much appreciated. > > THe patches look ok to me BUT there is the political issue > that we will now divert, afaict this means that you can now create > iptables-nft rulesets that won't ever work in iptables-legacy. > > IMO its ok and preferrable to extending xt_(NF)LOG with a new revision, > but it does set some precedence, so I'm leaning towards just applying > the rest too. > > Pablo, Phil, others -- what is your take? I think the change is OK if existing rulesets will continue to work just as before and remain compatible with legacy. IMHO, new rulesets created using iptables-nft may become incompatible if users explicitly ask for it (e.g. by specifying an exceedingly long log prefix. What about --nflog-range? This series seems to drop support for it, at least in the sense that ruleset dumps won't contain the option. In theory, users could depend on identifying a specific rule via nflog range value. Cheers, Phil
