From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:237:300::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 585E5AC for ; Mon, 4 Dec 2023 05:01:18 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1rA8ZX-00083s-2R; Mon, 04 Dec 2023 14:01:15 +0100 Date: Mon, 4 Dec 2023 14:01:15 +0100 From: Florian Westphal To: Maciej =?utf-8?Q?=C5=BBenczykowski?= Cc: Pablo Neira Ayuso , Florian Westphal , Netfilter Development Mailinglist Subject: Re: does nft 'tcp option ... exists' work? Message-ID: <20231204130115.GA29636@breakpoint.cc> References: <20231203131344.GB5972@breakpoint.cc> <20231204094351.GC5972@breakpoint.cc> Precedence: bulk X-Mailing-List: netfilter-devel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Maciej Żenczykowski 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 (where 34 is the kind/option you are looking for).