> On 5 Dec 2019, at 08:56, Jeremy Sowden <jeremy@azazel.net> 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