> On 5 Dec 2019, at 08:56, Jeremy Sowden <jeremy@xxxxxxxxxx> wrote: > > On 2019-12-03, at 16:06:52 +0000, Kevin Darbyshire-Bryant wrote: >> Greetings. The following patch is similar to one I submitted as an >> RFC quite a while back (April). Since then I've realised that the >> option should have been in the 'set mark' family as opposed to 'save >> mark' because 'set' is about setting the ct mark directly, whereas >> 'save' is about copying a packet's mark to the ct mark. >> >> Similarly I've been made aware of the revision infrastructure and now >> that I understand that a little more have made use of it for this >> change. Hopefully this addresses one of Pablo's concerns. >> >> I've not been able to address the 'I'd like an nftables version'. >> Quite simply it is beyond my knowledge and ability. I am willing to >> contribute financially if someone wishes to step up to the nftables >> plate...yes I'd like to see the functionality implemented *that* much. > > I'll do it (no financial contribution required :)). There is one thing I > want to find out before I get started. Hi Jeremy, You’ll permit me to make a donation in appreciation of your efforts though? I’m not totally convinced that what I’ve submitted for x_tables is the ‘perfect’ way of implementing the function so it’s a plea for guidance as much as anything :-) > Pablo, comparing the x_tables and nftables connmark implementations I > see that nftables doesn't support all the bit-twiddling that x_tables > does. Why is this? Was it not wanted or has it just not been imple- > mented? > > J. Thanks, Kevin
Attachment:
signature.asc
Description: Message signed with OpenPGP
