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


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 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.

On ipq it is build, but it is included in package kmod-sched which is not installed by default

1 Like

Ok, after upgrading to 21.02.3 I noticed this error:
daemon.err modprobe: failed to find a module named act_ipt

Checking the older logs I see this has actually been going on for a while but I don't see anything wrong besides this warning.

If that statement is correct, perhaps there is a dependency issues with the package? Meaning it should also want to pull in whatever package provides that module... is it kmod-sched? Open a ticket upstream?

Got rid of the act_ipt module from the load list:


Ha! I didn't realize that you ARE upstream, thanks for the fix :smiley:

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