On Mon, Dec 4, 2023 at 5:01 AM Florian Westphal <fw@xxxxxxxxx> wrote: > Maciej Żenczykowski <zenczykowski@xxxxxxxxx> wrote: > > wrt. the fix, perhaps this should be fixed both in the kernel and in userspace? > > it seems wrong to have unpredictable endian-ness dependent kernel logic, > > but a userspace fix/workaround would be easier to deploy... > > Right. > > > Is there some way I could feed raw nf bytecode in via nft syntax (if > > no... should support for this be added?) ? > > You could try this: > > tcp option @34,8,8 == 34 So this seems to mean @number(34),offset(8),length(8) == 34 And I understand the idea, but don't understand where the two 8's are coming from. Is this counting bits? bytes? ( http://netfilter.org/projects/nftables/manpage.html "RAW PAYLOAD EXPRESSION" seems to suggest it counts bits) If it's counting bits, shouldn't it be @34,0,8 == 34 My understanding is that tcp options (except for eol[0] and nop[1]) are (u8 kind >=2, u8 length >=2, length-2 data bytes...), so kind is at offset 0... > (where 34 is the kind/option you are looking for). I tried replacing 'tcp option fastopen exists' with 'tcp option fastopen length ge 0' and that seems to work. (I also tried 'tcp option fastopen kind eq 34' but I guess the nft binary is too new and no longer supports 'kind') Furthermore, I realized that really mangle postrouting 'reset tcp option fastopen' is a better solution to my particular problem. (I think stripping out the tcp fastopen option from the syn disables fastopen without causing a blackhole and thus an extra RTT roundtrip) I'll give your suggestion a try too.
