netdev - Re: [netfilter-core] [ANN] net-next is OPEN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240124121343.6ce76eff@kernel.org>
Date: Wed, 24 Jan 2024 12:13:43 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, David Ahern
 <dsahern@...nel.org>, coreteam@...filter.org,
 "netdev-driver-reviewers@...r.kernel.org"
 <netdev-driver-reviewers@...r.kernel.org>, Hangbin Liu
 <liuhangbin@...il.com>, netfilter-devel@...r.kernel.org
Subject: Re: [netfilter-core] [ANN] net-next is OPEN

On Wed, 24 Jan 2024 21:02:16 +0100 Pablo Neira Ayuso wrote:
> On Wed, Jan 24, 2024 at 11:40:57AM -0800, Jakub Kicinski wrote:
> > Hm, odd, it's there:
> > 
> > $ ls /lib64/xtables/libxt_conntrack.so
> > /lib64/xtables/libxt_conntrack.so
> >
> > but I set a custom LD_LIBRARY_PATH, let me make sure that /lib64 
> > is in it (normal loaded always scans system paths)!  
> 
> Could you also check your ./configure output for iptables? It shows
> the directory where the .so file are search and found:
> 
>   ...
>   Xtables extension directory:          /usr/lib/xtables

I'm using the OS iptables, I was hoping that for net/ tests
OS iptables should be good enough :S Is there a way to get
the info you're after?

$ iptables -V 
iptables v1.8.8 (nf_tables)

> > > What is the issue?  
> > 
> > A lot of the tests print warning messages like the ones below.
> > Some of them pass some of them fail. Tweaking the kernel config
> > to make sure the right CONFIG_IP_NF_TARGET_* and CONFIG_IP_NF_MATCH_*
> > are included seem to have made no difference, which I concluded was
> > because iptables CLI uses nf_tables here by default..  
> 
> Please, check if the symlink refers to -legacy or -nft via:
> 
> $ ls -la /usr/sbin/iptables

Ah, neat:

$ ls -la /etc/alternatives/iptables
lrwxrwxrwx. 1 root root 22 Jan  7 22:10 /etc/alternatives/iptables -> /usr/sbin/iptables-nft
$ ls -la /usr/sbin/iptables
lrwxrwxrwx. 1 root root 26 Jan  7 22:10 /usr/sbin/iptables -> /etc/alternatives/iptables

> > [435321]$ grep -nrI "Warning: Extension" .
> > ./6-fib-tests-sh/stdout:305:# Warning: Extension MARK revision 0 not supported, missing kernel module?  
> 
> This could come from either legacy or nftables:
> 
> libxtables/xtables.c:                                   "Warning: Extension %s revision 0 not supported, missing kernel module?\n",
> iptables/nft.c:                         "Warning: Extension %s revision 0 not supported, missing kernel module?\n",
> 
> both have the same error.
> 
> if that is the nftables backend, it might be also that .config is
> missing CONFIG_NF_TABLES and CONFIG_NFT_COMPAT there, among other
> options.

FWIW full config:

https://netdev-2.bots.linux.dev/vmksft-net-mp/results/435321/config

CONFIG_NFT_COMPAT was indeed missing! Let's see how it fares with it enabled.