On Wed, Jul 27, 2022 at 5:54 PM Randy MacLeod <[email protected]> wrote: > > Add new NF* configs to enable more nftables features. > > Previously 27/310 of the nftables ptests failed, mainly due to 'missing' > kernel modules. It's impossible to know which nftables features will be used > so > add more configs to ensure that most nftables features used by nft work. > > The added features are: > > NF_CONNTRACK_TIMEOUT > enables support for connection tracking timeout extension. > This allows you to attach timeout policies to flow via the CT target. > > NF_FLOW_TABLE > adds the flow table core infrastructure. > > NF_FLOW_TABLE_INET > adds the flow table mixed IPv4/IPv6 support. > > NFT_NUMGEN > adds the number generator expression used to perform incremental > counting and random numbers bound to a upper limit. > > NFT_OSF > allows matching packets from an specific OS. > > NFT_QUOTA=m > adds the "quota" expression that you can use to match enforce bytes quotas. > > NFT_SYNPROXY=m > The SYNPROXY expression allows you to intercept TCP connections and > establish them using syncookies before they are passed on to the > server. This allows to avoid conntrack and server resource usage > during SYN-flood attacks. > > This brings the nftables-1.0.4 ptest resutls from: > [OK] 283 [FAILED] 27 [TOTAL] 310 > to: > [OK] 294 [FAILED] 16 [TOTAL] 310 > The rest of the tests should and will be fixed eventually. >
Thanks for the branch information on this, it definitely helps .. and yah, we'd want to not only merge this to 5.15, but it needs to get to master as well. So it will be a consistent set of .scc for this, and future released kernels. I'm still torn / deciding on adding the extra modules into the existing .cfg though. We try to stay away from 'just in case' or all yes/mod config type fragments, and instead drive them by the needs of applications/frameworks. I've actually been thinking about making the feature more granular as I'm juggling kubernetes upgrades, docker, etc, and they all want a different mix of modules and built-ins. In this case, I'd prefer that we not add the new modules into the existing fragment. It isn't just the additions of the modules, by themselves it is small .. It is more that I'd like to ensure we have good examples of how to split and make features targeted. Long story short. I'd suggest that we have a nft_test.scc file, which includes nf_tables.cfg, and then we just add these new configs into a nft_test.cfg and include it as well. Bruce > Signed-off-by: Randy MacLeod <[email protected]> > --- > features/nf_tables/nf_tables.cfg | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/features/nf_tables/nf_tables.cfg > b/features/nf_tables/nf_tables.cfg > index b8f73b76..5e539044 100644 > --- a/features/nf_tables/nf_tables.cfg > +++ b/features/nf_tables/nf_tables.cfg > @@ -3,6 +3,9 @@ CONFIG_NF_TABLES=y > CONFIG_NF_TABLES_INET=y > CONFIG_NF_TABLES_NETDEV=y > CONFIG_NFT_CT=m > +CONFIG_NF_CONNTRACK_TIMEOUT=y > +CONFIG_NF_FLOW_TABLE=m > +CONFIG_NF_FLOW_TABLE_INET=m > CONFIG_NFT_HASH=m > CONFIG_NFT_COUNTER=m > CONFIG_NFT_MASQ=m > @@ -12,8 +15,11 @@ CONFIG_NFT_LIMIT=m > CONFIG_NFT_CONNLIMIT=m > CONFIG_NFT_TUNNEL=m > CONFIG_NFT_NAT=m > +CONFIG_NFT_NUMGEN=m > CONFIG_NFT_OBJREF=m > +CONFIG_NFT_OSF=m > CONFIG_NFT_QUEUE=m > +CONFIG_NFT_QUOTA=m > CONFIG_NFT_REJECT=m > CONFIG_NFT_REJECT_INET=m > CONFIG_NFT_COMPAT=m > @@ -24,3 +30,4 @@ CONFIG_NF_TABLES_ARP=y > CONFIG_NF_TABLES_IPV6=y > CONFIG_NF_TABLES_BRIDGE=m > CONFIG_NFT_SOCKET=m > +CONFIG_NFT_SYNPROXY=m > -- > 2.32.0 > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11522): https://lists.yoctoproject.org/g/linux-yocto/message/11522 Mute This Topic: https://lists.yoctoproject.org/mt/92659340/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
