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 8E439E6 for ; Mon, 4 Dec 2023 01:43:53 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1rA5UV-0006tM-CS; Mon, 04 Dec 2023 10:43:51 +0100 Date: Mon, 4 Dec 2023 10:43:51 +0100 From: Florian Westphal To: Florian Westphal Cc: Maciej =?utf-8?Q?=C5=BBenczykowski?= , Netfilter Development Mailinglist Subject: Re: does nft 'tcp option ... exists' work? Message-ID: <20231204094351.GC5972@breakpoint.cc> References: <20231203131344.GB5972@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: <20231203131344.GB5972@breakpoint.cc> User-Agent: Mutt/1.10.1 (2018-07-13) Florian Westphal wrote: > Maciej Żenczykowski wrote: > > FYI, I upgraded the router to OpenWrt 23.05.2 with 5.15.137 and it > > doesn't appear to have changed anything, ie. 'tcp option fastopen > > exists' still does not appear to match. > > > > Also note that I'm putting this in table inet filter postrouting like > > below... but that shouldn't matter should it? > > No, this is an endianess bug, on BE the compared byte is always 0. We could fix this from userspace too: ... exists -> reg32 != 0 ... missing -> reg32 == 0 currently nftables uses &boolean_type, so the compare is for 1 byte. We could switch this to 32 bit integer type, this way it will no longer matter if the kernel stores the number at offset 0 or 3. Phil, Pablo, what do you think?