Normal to see missing modules act_ipt and sch_fq_codel?

I have my RPi4 setup to use SQM, fd_codel/simple.qos and it works to reduce bufferbloat, however, I am seeing errors in logread output indicating that I am missing missing modules. Is this a false positive? Which package even provides these? I did not see them when searching in the build system's make nconfig tree.

Mon Sep  6 11:54:03 2021 daemon.err modprobe: failed to find a module named act_ipt
Mon Sep  6 11:54:03 2021 daemon.err modprobe: failed to find a module named sch_fq_codel
Mon Sep  6 11:54:03 2021 daemon.err modprobe: failed to find a module named act_ipt
Mon Sep  6 11:54:03 2021 daemon.err modprobe: failed to find a module named sch_fq_codel

Seeing this error on multiple architectures (ipq40xx, ath79, xrx200) after using a 21.02 build created with imagebuilder.

1 Like

Well, the question is, will this still complain if a required functionality is neither built-in nor found as a module. Because unconditionally silencing this seems worse than having a few false positives in logread, at least IMHO (but then I had my fingers in getting the verbose version implemented, so I am hardly objective here).

1 Like

agreed.....

These errors can be either:
a) false positives, for example if a qdisc is built into the kernel instead of as a module, like fq_codel
b) true positives, if a required module does not exist at all

The second case seems worth causing an error, after all the end-user should know to remedy this. But that job might be deferred to verify_qdisc(), by including a "; qdisc was neither built-in nor found as module" into the error message.

1 Like

In the case of the second error (which I also experienced), I'm not entirely sure what it is down to - it relates to the act_ipt module, but I assume this is pulled in as a result of something else, and assume it is sqm related given the surrounding context. Though as far as I can tell everything else works, and I can't see an obvious package that is missing between 19 and 21

So SQM already checks whether a module is loaded already and will not complain or attempt to reload it in that case, but it will try to find/load modules not already loaded. And if act_ipt functionality was built into the kernel and not configured as a module, the act_ipt module does not exist and con not be loaded, so modprobe rightfully complains. BUT on OpenWrt the kmodloader binary insists on injecting that error into the log, and there is no easy way to redirect that into SQM's private log (as for all built-ins this error is going to come up on every sqm (re-)start, so quite often during normal uptimes of OpenWrt routers).

1 Like

I got just this one:
daemon.err modprobe: failed to find a module named act_ipt

That's not available as module and and neither built-in on xrx200:

$ grep -i act_ipt build_dir/target-mips_24kc_musl/linux-lantiq_xrx200/linux-5.10.64/.config
# CONFIG_NET_ACT_IPT is not set

Well, then at least some of the scripts will not work, so this seems like a true error report...
@tohojo, this is one of the cases where the error reporting seems to be worth its while.
I will have a go at prototyping something later this month.

Is it, really? What are we using act_ipt for, exactly?

IN https://github.com/tohojo/sqm-scripts/blob/master/src/simple.qos we set up the MARK chain, and then jump to it and use --set-mark, which seems to be an iptables action.

But that's just iptables rules? act_ipt is a TC action to interface with iptables, which I don't think we're using? AFAICT we only use action mirred for TC?

Good point, I guess it is time to try whether excluding act_ipt from loading causes actual regressions in sqm's functionality.... I do not remember when and why act_ipt was added to the list of modules to load.