[Solved] Changing/adapting kernel options for your needs

Hi all,
I was several times told that I should never touch make kernel_menuconfig, because it is easy to mess up thing that way. Also, all needed things must be selected in kernel automatically. Ok, now I have added nftables to my image build and I need to enable some support for it in kernel. For example, I need NFT_LOG to be supported in kernel. As by default is is selected as

CONFIG_NFT_LOG=m

in kernel (checked kernel's .config file in build_dir). Now I need to have this option built in into kernel, hence

CONFIG_NFT_LOG=y

. How can I achieve that without using make kernel_menuconfig? The only place I've found was include/netfilter.mk, but I do not really know how to manipulate lines like $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_LOG, $(P_XT)nft_log),)) There is also not much documentation available. Can anyone help me with this? And also, what is real reason behind not touching make kernel_menuconfig? Wouldn't it be just easier to enable required options there?

You hit it right there. If you know what you're doing, that's how to configure kernel options. Most don't, hence the dire warnings.

1 Like

Ok, I must admit, that I'm not an expert in kernel, but I just need to compile in some options (like described in mail above). How then shall I do? It is a bit strange, that you can't use one or the other package at full power, because it requires kernel options to be enabled. Is there any way to configure for example nft kernel module so that it will enable appropriate kernel option as 'y', not as 'm'?

There is, but it requires changing various make-system files. Having dealt with that mess in the past, I leave it to experts and deal with having to tweak a kernel configuration here and there as I need.

Good to hear that there are other nftables fans out there. I'm looking forward to the day when OpenWRT adopts it over iptables.

That is a bit different topic, but yes. My goal is totally replace iptables with nftables. So far I have succeeded. I do not have iptables on my router anymore. Only plain nftables, but here I'm struggling with rule logging. Seems like something is wrong with kernel options. Continue searching for solutions...

Do you have ulogd installed, configured, and running? Configuring ulogd was a major learning experience for me.

If it helps, here's some of the modules loaded on a box I have that is running nftables

jeff@apu:~$ lsmod | egrep 'nf|log'
nfnetlink_queue        24576  0
nft_nat                16384  5
nft_chain_nat_ipv4     16384  2
nf_nat_ipv4            16384  1 nft_chain_nat_ipv4
nf_nat                 28672  2 nft_nat,nf_nat_ipv4
nft_exthdr             16384  4
nf_conntrack_ipv6      20480  41
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
nf_conntrack_ipv4      16384  47
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nft_ct                 20480  21
nft_log                16384  50
nft_meta               16384  122
nft_set_bitmap         16384  4
nft_set_hash           24576  18
nft_set_rbtree         16384  12
nf_tables_inet         16384  11
nf_tables_ipv6         16384  1 nf_tables_inet
nf_tables_ipv4         16384  2 nf_tables_inet
nf_tables              86016  594 nft_ct,nft_nat,nft_set_bitmap,nft_chain_nat_ipv4,nft_set_hash,nft_exthdr,nf_tables_ipv6,nf_tables_ipv4,nft_meta,nft_set_rbtree,nft_log,nf_tables_inet
nfnetlink_log          20480  107
nfnetlink              16384  10 nfnetlink_log,nfnetlink_queue,nf_tables
nf_conntrack          131072  6 nft_ct,nft_nat,nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
libcrc32c              16384  4 nf_conntrack,xfs,raid456,nf_nat

1 Like

No, I do not have ulogd installed. Do you think it might be the problem? In my case nftables just returns error code if I want to add log rule. For example, if I enter: nft add rule ip ipv4_filter incoming tcp dport {ssh} log accept then I get error Error: Could not process rule: No such file or directory.
lsmod in my case returns:

root@LEDE:~# lsmod | egrep 'nf|log'
nf_conntrack           54664  9 nft_ct,nf_nat_ipv6,nf_nat_ipv4,nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat_masquerade_ipv6,nf_nat_masquerade_ipv4,nf_nat,nf_conntrack_rtcache
nf_conntrack_ipv4       5507  2 
nf_conntrack_ipv6       5884  1 
nf_conntrack_rtcache    2834  0 
nf_defrag_ipv4          1020  1 nf_conntrack_ipv4
nf_defrag_ipv6         13469  1 nf_conntrack_ipv6
nf_nat                  8935  6 nft_nat,nf_nat_ipv6,nf_nat_ipv4,nf_nat_redirect,nf_nat_masquerade_ipv6,nf_nat_masquerade_ipv4
nf_nat_ipv4             3591  1 nft_chain_nat_ipv4
nf_nat_ipv6             3791  1 nft_chain_nat_ipv6
nf_nat_masquerade_ipv4    1677  1 nft_masq_ipv4
nf_nat_masquerade_ipv6    1613  1 nft_masq_ipv6
nf_nat_redirect         1051  2 nft_redir_ipv6,nft_redir_ipv4
nf_reject_ipv4          1987  2 nft_reject_ipv4,nft_reject_inet
nf_reject_ipv6          2248  2 nft_reject_ipv6,nft_reject_inet
nf_tables              43694 34 nf_tables_inet,nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet,nft_redir_ipv6,nft_redir_ipv4,nft_redir,nft_rbtree,nft_nat,nft_meta,nft_masq_ipv6,nft_masq_ipv4,nft_masq,nft_log,nft_limit,nft_hash,nft_exthdr,nft_ct,nft_counter,nft_chain_route_ipv6,nft_chain_route_ipv4,nft_chain_nat_ipv6,nft_chain_nat_ipv4,nf_tables_ipv6,nf_tables_ipv4
nf_tables_inet           895  0 
nf_tables_ipv4          1346  3 nf_tables_inet
nf_tables_ipv6          1346  1 nf_tables_inet
nfnetlink               4419  3 nf_tables,nfnetlink_queue,nfnetlink_log
nfnetlink_log           6883  0 
nfnetlink_queue         8438  0 
nft_chain_nat_ipv4       984  0 
nft_chain_nat_ipv6      1048  0 
nft_chain_route_ipv4     980  0 
nft_chain_route_ipv6    1108  0 
nft_counter             1817  2 
nft_ct                  2353  1 
nft_exthdr              1232  0 
nft_hash                8816  1 
nft_limit               2176  0 
nft_log                 1767  0 
nft_masq                 879  2 nft_masq_ipv6,nft_masq_ipv4
nft_masq_ipv4            787  0 
nft_masq_ipv6            787  0 
nft_meta                2912  2 
nft_nat                 1960  0 
nft_rbtree              2063  0 
nft_redir               1138  2 nft_redir_ipv6,nft_redir_ipv4
nft_redir_ipv4           788  0 
nft_redir_ipv6           852  0 
nft_reject              1117  3 nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet
nft_reject_inet         1247  0 
nft_reject_ipv4          789  0 
nft_reject_ipv6          789  0

Hmmm, your rule syntax looks OK to me, but I'm only an nftables hacker.

frag frag-off 1 log prefix "DROP: frag offset of 1: " group 2 drop

is in one of my rulesets. I typically load mine through a call to nft -f <blahblah.nft> and include statements, not from the command line. Maybe it is that nft doesn't know what table to associate that with?

1 Like

You jogged my memory, from my git logs of trying to get nftables to work:

    Set up log1, log2, and log3 for groups 0,1,2
    
    Not preventing kern.log,
    but group isn't in nftables yet
    
    Looks as though if neither is specified, syslog is used

I seem to remember that if you don't specify a group that ulogd doesn't see anything on netlink

Edit: "but group isn't in nftables yet" refers to me having changed my ulog config, but not my nftables rules files yet.

This was on Ubuntu, where there is a standard syslog facility. I've also long since moved to having the group number correspond with the ulogd number.

1 Like

I also load my rules via file normally. Same situation, same error.
Did you have any problems after installing nftables that logging was not working out of the box? I still wondering is ulog is really necessary as such. As I understand, nftables log should at least output log to dmesg as by default. Have you changed any kernel option for logging to work? I really can't find a clue. All modules are loaded, so most likely it is not kernel problem. Just don't understand why nftables can't recognize log statement.

I did the config on Ubuntu, which may have a different way of handling the kernel's logging path than what is implemented in OpenWRT. As I understand the architecture, ulogd is a listener on netlink so that its a "tree falls in the forest" kind of thing. If you have a valid logging group set, the message should go out on netlink to consumers (and not to syslog).

I built from git on Ubuntu as the packaged versions were far too old, so I can't comment on what packages are needed for OpenWRT. There it was/is for libmnl, libnftl, and nftables and then ulogd2 as a package.

Biggest problem I have now is that nftables does not recognize log statement. Let's see what I will find. I'm also in contact with nftables developers. I'll update here with my findings about the problem. Thanks for help!

1 Like

It took some time, but issues is solved. As jeff suggested, it was ulogd configuration problem. Now everything works fine, just I always need to use group statement together with log in case I use nfnetlink_log.
Thanks for the help! It was one more proof, that in normal cases kernel config shall not be altered :sunglasses:.

I marked the topic as solved.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.