<stintel>
robimarko: thanks, great commit message, but in this case I'd also add a comment above the default n
<stintel>
to avoid the same change being done in the future
<stintel>
6 months from now nobody will remember
<robimarko>
stintel: Good idea, if it works I will add it in the PR
<stintel>
now back to deciding which rackmount kit to order for raspberry pi
<stintel>
tidying up the homelab :)
<Znevna>
don't debloat it too much :P
<rmilecki>
does anyone have an idea how to deal with unused kernel modules? if they are loaded they can slow down network performance, I described that in:
<rmilecki>
I want to have qos-scripts installed in case i need it, but I don't want it (actually: iptable_raw.ko) to slow down my network when I don't use QoS
<Znevna>
iptables boo :P
nitroshift has joined #openwrt-devel
<gch981213>
rmilecki: Implement the on-demand module loading done by desktop distros?
<gch981213>
Not sure how much work is that.
<rmilecki>
jow: do you have any advise by some chance?
<karlp>
mv it out of the way when you don't want it, dual boot style? :)
<stintel>
disable autoload for the module and manually load it from the qos-scripts init script?
<rmilecki>
stintel: oh...
<rmilecki>
that sounds better I guess
<stintel>
although it seems to be a dependency of NETFILTER_XT_TARGET_CT
<mrkiko>
In my opinion, ignoring PRs by choice is really a bad thing. If you don't want something, don't like it or find it too risky to accept, say so. At least the person on the other side knows. I know sometimes the person on the other side will pressure and that makes things more complicated, but ignoring patches or PRs by choice is simply bad, and confuses things furthermore when PRs backlog becomes
<mrkiko>
longer.
<rmilecki>
stintel: can you help me understand that NETFILTER_XT_TARGET_CT bit?
<gch981213>
Oh. Our kmodloader can already do that.
<gch981213>
rmilecki: It seems that you can just remove the autoload and kernel will ask /sbin/modprobe to load the module when it's needed.
<mrkiko>
rmilecki: and you can change that location via a sysfs file if I remember correctly
<mrkiko>
rmilecki: or maybe not, but surely via .config
<rmilecki>
stintel: i know it's a symbol, i have it =m, but is there some dependency problem?
<rmilecki>
gch981213: i'm going to try that!
<rmilecki>
mrkiko: change location of what? sorry, I don't follow
<stintel>
rmilecki: unfortunately the whole nftables voodoo we do in OpenWrt is too complex for me to understand
Acinonyx has joined #openwrt-devel
<stintel>
just looking at the kernel, iptable_raw is a build dependency for NETFILTER_XT_TARGET_CT NETFILTER_XT_TARGET_NOTRACK NETFILTER_XT_TARGET_TRACE
<stintel>
iiuc we use NETFILTER_XT_TARGET_CT in firewall4
<rmilecki>
oh...
<stintel>
question is, is it also a runtime dependency ... in that case, disabling autoload for iptable_raw isn't going to help you
<rmilecki>
i'm still working on 21.02 here, but that may be a problem if I start testing 22.03
Acinonyx_ has quit [Ping timeout: 480 seconds]
<stintel>
rmilecki: it might not matter, firewall3 also uses the CT target
<rmilecki>
stintel: i don't get it... normally I don't get iptable_raw installed
<rmilecki>
unless i install qos-scripts
<rmilecki>
let me double check those dependencies
<stintel>
yeah like I said, I don't understand the black magic involved in OpenWrt netfilter packaging
<mrkiko>
rmilecki: the location of the binary you're going to call
<mrkiko>
rmilecki: doesn't need to be /bin/modprobe, you can change that
<stintel>
ok so ipt-raw is a dep of iptables-mod-conntrack-extra
<stintel>
and iptables-mod-conntrack-extra is a dep of qos-scripts
<rmilecki>
correct
<stintel>
so I guess I am confused by the dependency in the kernel
<jow>
rmilecki: advice regarding the unused kmods
<jow>
?
<jow>
gch981213: iirc we alread do on-demain kmod loading
<jow>
*already do on-demand
<rmilecki>
jow: yes
<rmilecki>
jow: should I just try dropping AUTOLOAD from iptable_raw?
<rmilecki>
and probably conntrack-extra.ko (or whatever)
<gch981213>
jow: I later found that out :D The module mentioned by rmilecki comes with an AutoProbe so it's always loaded on boot.
<jow>
rmilecki: hmm
<jow>
rmilecki: I think we patch iptables to not invoke modprobe for missing modules
hurricos has joined #openwrt-devel
<jow>
rmilecki: if you remove the autoprobe of iptables modules you will also need to reenable modprobe in iptables
<rmilecki>
so if I drop AUTOLOAD, those will never get loaded?
<jow>
I think so, yes
<rmilecki>
jow: and the downside of doing that is...? :)
<jow>
I think back in the day we didn't have a functioning modprobe
<jow>
nowadays we do have it, but it is slow
<jow>
since it is not using a precalculated module cache, it will re-scan the module directory on each invocation
<rmilecki>
well, I don't load module every minute
<jow>
and the kernel can spew a lot of module load requests under certain conditions
<rmilecki>
ah
<jow>
but this is of no concern as we already to autoload by default
<jow>
I think there speaks nothing against reenabling modprobe in iptables
<rmilecki>
so idea solution would be to:
<rmilecki>
1. use cache for loading modules
<rmilecki>
2. re-enable probing modules
<rmilecki>
3. drop AUTOLOADs?
<jow>
I would...
<jow>
1. reenable modproble in iptables
<jow>
2. drop AUTOLOAD for non-essential iptables modules
<jow>
why iptables btw?
<jow>
we switched to nft in 22.03 and master
<rmilecki>
working on 21.02 still
<jow>
ah
<jow>
hm
<jow>
not sure if we want that kind of behavioral changes so late into the release
<jow>
it's oldstable after all
<rmilecki>
it's for close to EOL product and switching to 22.03 & DSA would probably cost more time than just fixing up QoS
<rmilecki>
jow: do we have autoloading in 22.03 enabled?
<jow>
rmilecki: yes
<rmilecki>
(i meant loading on demand)
<jow>
# cat /proc/sys/kernel/modprobe
<jow>
/sbin/modprobe
<rmilecki>
jow: ok, sounds good
<rmilecki>
jow: well, it's the same in 21.02 ;)
<rmilecki>
# cat /proc/sys/kernel/modprobe
<rmilecki>
/sbin/modprobe
<jow>
that's for kernel side module load requests
<jow>
however I am not sure if the kernel does mod load requets for iptables table and target mods
<rmilecki>
jow: so for testing I could do: rm ./package/network/utils/iptables/patches/102-iptables-disable-modprobe.patch
<rmilecki>
?
<jow>
yes
<rmilecki>
jow: thank you
nitroshift has quit [Quit: Gone that way --->]
<jow>
dhewg: ping
<jow>
dhewg: I am currently testing latest luci with current master in qemu-x86 using mac80211-hwsim
<jow>
dhewg: when calling `ubus call iwinfo freqlist '{ "device": "radio0" }'` I see that a portion of the resulting frequency entries lacks the `band` attribute
<jow>
hmm, interesting - rpcd required a restart to put out iwinfo results again
<jow>
allright, it seems fine now
<dhewg>
hmm ok
<dhewg>
you only need to restart rpcd if you have another libiwinfo.so binary, and I think upgrading the rpcd package does that? so ignoring manually messing around it should be fine
<rmilecki>
(btw kmodloader complains about unrecognized -r option)
<rmilecki>
i don't see qos loading ipt_raw at all
<rmilecki>
it seems to load only few modules from the kmod-ipt-conntrack-extra package
<rmilecki>
(like xt_connmark
<rmilecki>
so I'm wondering whether we should split kmod-ipt-conntrack-extra into smaller packages
<rmilecki>
and make qos select only what it really needs
<stintel>
ok so iiuc, the iptable_raw module creates the raw table. this table is used by the deprecated NOTRACK extension (-j NOTRACK), or CT notrack (-j CT --notrack), or TRACE (-j TRACE)
<stintel>
firewall3 has references to notrack, so I conclude that in a default image, that doesn't have kmod-ipt-conntrack-extra, one could potentially add a firewall rule that isn't even going to work ?
<stintel>
and firewall4 also has references to notrack, so same problem could happen there
minimal has joined #openwrt-devel
<stintel>
just tried a notrack rule with firewall4 and no iptable_raw installed, doesn't error, nft list ruleset shows the rule is there
<stintel>
don't have any setup with iptables around anymore
xes has quit [Quit: bye..]
<f00b4r0>
stintel: correct, I've been bitten by this before (and failed to report it ;P)
<f00b4r0>
(on fw3)
<stintel>
right, so for the firewall3 case ... I'd even argue we should *add* iptable_raw.ko as a dependency
<stintel>
or does it produce a clear enough error that points you to opkg install kmod-ipt-raw ?
<rmilecki>
stintel: fine, if we get back to loading modules on demand
<rmilecki>
(when needed)
<f00b4r0>
iirc there's no error
<stintel>
might be a niche use case, so maybe not having the dep but producing a clear error ?
<stintel>
+is better
<stintel>
f00b4r0: so there's no error, but the rule simply isn't there ?
xes has joined #openwrt-devel
<f00b4r0>
i don't remember exactly tbh. I do remember myself having to manually install kmod-ipt-raw for some shenanigans of mine
<rmilecki>
stintel: if you tell me how to test it, I can report back
<f00b4r0>
since then I made it a default in my images :)
<stintel>
:P
<stintel>
rmilecki: one moment
<f00b4r0>
although given rmilecki's finding, I might eventually change that given the potential perf impact
<rmilecki>
stintel: i'll be leaving in minutes though, so i'll come with answer later
<f00b4r0>
i think i mentioned this before but a tunable in conntrack-extra to select which protos should be "helped" would be nice
<f00b4r0>
8/10 of the ones that are auto-enabled I don't need.
<karlp>
does anyone know a reference for naming rules/conventions on device tree files?
<karlp>
the openwrt sunxi makefile is currently assuming things to be soc-board.dtb, with vendor stripped out, and that's.... somewhat true? at least true for all the currently supported boards, but it's not all of them, and I can't find any particular rule anywhere
<karlp>
even just arch/arm/boot/dts overall is a mix of files with vendor-part or no vendor section.
<robimarko>
There isnt a written down rule
<robimarko>
Usually its soc-board.dtb
<karlp>
there's some really confusing loops ofr substituting _ and , around sysupgade and image building to try and keep macro names and dts compat stuff happy.
<karlp>
it's.... lots of fun :)
Tapper has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
dangole has quit [Remote host closed the connection]
<dhewg>
make syntax gets cryptic with just a little complexity
<karlp>
my concern is the layers of it.
<karlp>
stintel: so, yeah, that finally works, but wow, so many errors. I am not filled with joy at this, but ... it does appear to work, using both the sdcard.img.gz and the sdcard.img. https://paste.jvnv.net/view/djhv8
<stintel>
karlp: the broken pipes happen everywhere afaik
<karlp>
I'm not used to it from my old ath79 world.
<karlp>
I gave up on fit images, caused too many other problems with needing bigger bootm configs for uboot, and ... after playing with it, I'm really not seeing any benefits right now.
<karlp>
it avoids the word "legacy" on teh bootlog, that's about it though.
<stintel>
:P
<stintel>
one advantage is that you don't have to worry about changing the loadaddr for the dtb in case the kernel grows too large
<stintel>
and the u-boot env becomes a tiny bit less bloated
<karlp>
I'm cuyrrently still ignoring uboot env. refusing more nightmares right now.
<karlp>
I had it save my default config to my mmc env, then next boot it didn't have any of _actual_ "defaults_ so it didn't boot anymore.
<stintel>
right, I was thinking of qoriq/m300
<stintel>
not sure how u-boot env behaves on my sunxi devices
<karlp>
it doesn't
<stintel>
:D
<karlp>
there's no ubootenv config (yet)
<karlp>
I've added it, but none of the existing ones do anything at all with it.
<karlp>
it's just entirely left as whatever the uboot defconfig defined, no further thought