Re: TCPOPTSTROP can be repalced with undocumented "reset tcp option opt"

[Florian Westphal <fw@strlen.de>]

Niklas Beierl <niklasbeierl@posteo.net> wrote:
> I found myself in the situation of needing the behavior from the legacy  
> TCPOPTSTRIP target. On the netfilter wiki, this target is listed under 
> "Unsupported extensions" with the very brief comment "consider native 
> interface, need to extend nft_exthdr.c".
> 
> https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables#TCPOPTSTRIP

I've removed this bit, its outdated.

> reset tcp option OPT
> 
> which seems to turn the selected option into NOPs. To my understanding 
> this is equivalent to  "-p tcp -j TCPOPTSTRIP --strip-options OPT".

It is.

> I think this should be mentioned in the wiki on the Mangling packet 
> headers page and also with regards to replacing TCPOPTRESET. How can I 
> make this happen? Can I get credentials to the wiki somehow? Should I 
> instead write it up and send it to someone?

You could send a patch for iptables, specifically
extensions/libxt_TCPOPTSTRIP.c and add ".xlate" support together with a
libxt_TCPOPTSTRIP.txlate file (with tests).

Then the wiki could link to that just like it does for other supported
extensions.

> Furthermore, I would like to understand (and document) the general 
> syntax for setting tcp options. I am especially curious whether tcp 
> options can also be set if the field is not known to the netfilter code.

Whats your use case?

You can do
tcp option @255,8,8 255

(locate option 255, offset 8 bit, fetch 8 bits), then compare to 255.
Same syntax as raw payload expressions.

> I guess there are issues with encoding the cli-passed value 
> appropriately in the header field?
> 
> Lastly I was wondering whether it is also possible to add or entirely 
> remove option fields from tcp headers - as opposed to just NOPing them?

Not at this time, its more expensive since data needs to be moved.
NOPing is much simpler.