potential bug filed over at openwrt's tracker #119
Comments
|
It looks like a build problem to me, involving a heavily patched "vendor kernel". Probably Kevin knows the most about the nuances of this. |
|
Jonathan Morton <[email protected]> writes:
It looks like a build problem to me, involving a heavily patched
"vendor kernel". Probably Kevin knows the most about the nuances of
this.
Yeah, it's definitely something weird in the build system; question is
whether this is an upstream openwrt issue or if it's patched...
|
|
Does it require some particular symbol setting enabled in the kernel build conf? syslog prints
and
|
|
n8v8R <[email protected]> writes:
Does it require some particular symbol setting enabled in the kernel build conf?
syslog prints
> sch_cake: Unknown symbol nf_conntrack_find_get (err -2)
> sch_cake: Unknown symbol nf_ct_get_tuplepr (err -2)
and `errno 2` hints
> ENOENT 2 No such file or directory
Those look like missing conntrack functions; they should be ifdef'ed out
if conntrack is not enabled, though:
#if IS_REACHABLE(CONFIG_NF_CONNTRACK)
|
|
What is potentially missing and where? |
|
n8v8R <[email protected]> writes:
`lsmod | grep sch_cake`
```
nf_conntrack 77824 48 sch_cake,nf_nat_pptp,nf_conntrack_pptp,ipt_MASQUERADE,xt_state,xt_nat,xt_helper,xt_conntrack,xt_connmark,xt_connlimit,xt_connbytes,xt_REDIRECT,xt_CT,nft_redir_ipv6,nft_redir_ipv4,nft_redir,nft_nat,nft_masq_ipv6,nft_masq_ipv4,nft_masq,nft_flow_offload,nft_ct,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_masquerade_ipv6,nf_nat_masquerade_ipv4,nf_nat_irc,nf_conntrack_ipv6,nf_nat_ipv6,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat_h323,nf_nat_ftp,nf_nat_amanda,nf_nat,nf_flow_table,nf_conntrack_tftp,nf_conntrack_snmp,nf_conntrack_sip,nf_conntrack_rtcache,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp,nf_conntrack_broadcast,nf_conntrack_amanda
sch_cake 40960 0
```
___
```
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CONNTRACK_RTCACHE=m
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
# CONFIG_NF_CONNTRACK_TIMESTAMP is not set
CONFIG_NF_CONNTRACK_LABELS=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_BROADCAST=m
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
CONFIG_NF_CONNTRACK_SNMP=m
CONFIG_NF_CONNTRACK_PPTP=m
# CONFIG_NF_CONNTRACK_SANE is not set
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_IPV6=m
```
___
What is potentially missing and where?
Nothing, it looks like?
The thing is also that the error you posted should make the module load
fail. So since sch_cake is in fact loaded, I'm wondering if the error is
a false positive? Maybe the module load order is off? I.e., if it tries
to load the qdisc before conntrack at boot, that will probably fail,
but then it tries again later (when the qdisc is applied), and it
succeeds?
|
|
Fine if it is a ghost, just seeing such error reports in the logs is a bit confusing and led me to a quest for the cause of it and potential remedy. |
|
n8v8R <[email protected]> writes:
Fine if it is a ghost, just seeing such error reports in the logs is a
bit confusing and led me to a quest for the cause of it and potential
remedy.
I think it is; normally this would be fixed by module dependency
resolution. So maybe that is borked? Not sure how that is done on
openwrt, actually...
|
|
If am not mistaken interdependency of module load order (e.g. load B only after A is loaded) is not feasible in OpenWrt. Instead the order seems being statically set via
|
|
Suppose the issue can be closed since the conclusion appears to be a negligible ghost with no inclement impact (least I hope so) |
|
n8v8R <[email protected]> writes:
If am not mistaken interdependency of module load order (e.g. load B
only after A is loaded) is not feasible in OpenWrt. Instead the order
seems being statically set via
* _/etc/modules-boot.d/_
* _/etc/modules.d/_
Right, well in that case maybe the fix for openwrt is just to drop a
file for sch_cake in there somewhere?
|
|
There is
but I am not sure how that fairs with regard to
|
|
n8v8R <[email protected]> writes:
There is
`ls -af /etc/modules.d/ | grep sch`
> 70-sched-core
> 75-sched-cake
> 72-sched-bpf
but I am not sure how that fairs with regard to
> Maybe the module load order is off? I.e., if it tries to load the
> qdisc before conntrack at boot, that will probably fail, but then it
> tries again later (when the qdisc is applied), and it succeeds?
I assume they're loaded in sort order; and the nf_conntrack file in that
dir isn't numbered, so it would come after. I think we may have found
the source of the error :)
|
|
To my understanding it is an alphanumerical order:
|
|
n8v8R <[email protected]> writes:
To my understanding is is a alphanumerical order:
* numericals first, lowest first and ascending
* alphabetical next, start with a and ascending
Yup, which puts '75-sched-cake' before 'nf-conntrack' :)
|
|
On Jan 10, 2020, at 12:43, Toke Høiland-Jørgensen ***@***.***> wrote:
n8v8R ***@***.***> writes:
> To my understanding is is a alphanumerical order:
>
> * numericals first, lowest first and ascending
> * alphabetical next, start with a and ascending
Yup, which puts '75-sched-cake' before 'nf-conntrack' :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Why is 75-sched-cake in there at all? sqm-scripts will try to load cake's module on start, so his might not be needed in there at all?
|
It is provided by kmod-sched-cake |
|
n8v8R <[email protected]> writes:
>Why is 75-sched-cake in there at all?
It is provided by *kmod-sched-cake*
I think it's standard to provide these files for all kernel modules on
openwrt. Since there's no module autoloading, if we get rid of it people
won't be able to use the qdisc outside of sqm-scripts, which is probably
not what we want...
|
|
Having changed /etc/modules.d/71-nf-conntrack and rebooted and the errors are not exhibiting any more |
|
n8v8R <[email protected]> writes:
Having changed
/etc/modules.d/71-nf-conntrack
/etc/modules.d/71-nf-conntrack-netlink
and rebooted and the errors are not exhibiting any more
Great, there we go, then! :)
|
|
@tohojo would you be kind enough to sponsor a PR at OpenWrt? |
|
n8v8R <[email protected]> writes:
@tohojo would be kind enough to sponsor a PR at OpenWrt?
Don't think I have permissions for that in the core openwrt repo...
|
|
not sure if this is still an issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://bugs.openwrt.org/index.php?do=details&task_id=2346 Has a report for issues with cake and conntrack which might be interesting.
The text was updated successfully, but these errors were encountered: