bbezak has quit [Ping timeout: 480 seconds]
<hurricos> Habbie: curious about the switch behind the ssg140's ports
goliath has quit [Quit: SIGSEGV]
<hurricos> Oh, oh no.
<hurricos> it's 🎵 abandoned hardware garbage 🎵
Lynx- has quit [Quit: Going offline, see ya! (]
Tapper has quit [Ping timeout: 480 seconds]
xback has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<dwfreed> woo
<owrt-2203-builds> Build [#222]( of `mvebu/cortexa53` completed successfully.
<stintel> I'll be non-LTS on my workstation for a while
<stintel> Arc GPU requires > 6.1
xback has joined #openwrt-devel
<stintel> well, not requires. it worked ok with 6.1, but OpenCL and VA-API didn't
<stintel> but so far it's a better experience than when I just got the Radeon RX5700XT
<stintel> really looking forward to the Arc Pro A40 (low profile) becoming available now
<stintel> planning to stuff one of those in the hifive unmatched - the nvidia in there is meh
SlimeyX has quit [Remote host closed the connection]
SlimeyX has joined #openwrt-devel
SlimeyX has quit []
SlimeyX has joined #openwrt-devel
<owrt-2203-builds> Build [#236]( of `at91/sama5` failed.
cmonroe has joined #openwrt-devel
Habbie has quit [Ping timeout: 480 seconds]
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
<dwfreed> oh that's cute, you can't *download* qosify sources without a functioning clang
<dwfreed> because include/ checks for clang in global scope
Habbie has joined #openwrt-devel
<stintel> wb Habbie :)
gch981213 has quit [Quit: Ping timeout (120 seconds)]
gch981213 has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
minimal has quit [Quit: Leaving]
matoro has quit [Quit: ZNC 1.8.2 -]
matoro has joined #openwrt-devel
hurricos has quit [Ping timeout: 480 seconds]
cp-- has joined #openwrt-devel
cp- has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
<KGB-2> has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
valku has quit [Quit: valku]
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
goliath has joined #openwrt-devel
rmb has quit [Quit: ZNC 1.8.2+deb2+b1 -]
rmb has joined #openwrt-devel
<Habbie> stintel, thanks! this reconnect was in my agenda :D KPN announced maintenance
slh_ is now known as slh64
goliath has quit [Quit: SIGSEGV]
nitroshift has joined #openwrt-devel
Tapper has joined #openwrt-devel
Guest3931 is now known as ynezz
Tapper has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
robimarko has joined #openwrt-devel
bbezak2 has quit []
bbezak has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
T-Bone has quit [Remote host closed the connection]
<stintel> Habbie: ah I thought the junipers might have messed up your network :D
<Habbie> haha
<robimarko> dwfreed: I though that issue got fixed with:
<dwfreed> robimarko: needs backport to 22.03
<dwfreed> that or it's not in a released 22.03
<dwfreed> For now I'm just building the latest release
<robimarko> dwfreed: Its not backported to 22.03
<dwfreed> the exact issue exists in 22.03, I see the same output as shown in that commit; so if someone wants to backport it
danitool has joined #openwrt-devel
<robimarko> ynezz: You here?
<ynezz> robimarko: yes
<robimarko> Its easier to write here than in GH
<robimarko> Basically, for whatever reason removing the default value means that those symbols dont get written to OpenWrt .config
<robimarko> And then they are not processed during build-time
<ynezz> indeed, I get it
<robimarko> Crazy thing is that if you run menuconfig they are set to =n
<robimarko> I have no idea how/what is evaluating KConfig options
cbeznea has joined #openwrt-devel
<robimarko> Ok, its in scripts/config
<robimarko> Since KERNEL_DEBUG_LL depends on KERNEL_EARLY_PRINTK its not visible hence KConfig is not setting its value
<robimarko> But in OpenWrt we are relying on its value being set
<robimarko> Even worse, KERNEL_DEBUG_LL and KERNEL_DEBUG_LL_UART_NONE are not user selectable so they wont be set
nitroshift has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<robimarko> So, we can either make them user selectable or just set a default value back again.
<robimarko> I opted to just set the default value again so they get evaluated
nitroshift has quit [Quit: Gone that way --->]
<jow> this case should serve as a reminder to not prematurely accept rage cleanup commits in the future
<robimarko> I mean, I get why this looked not being able to break anything as default n is the default
<robimarko> And the PR was open for a while
<robimarko> I just need somebody to test the patch
<jow> yeah but given the complex environment we're in, a "looks like" is often not enough justification
<jow> (unless we accept breakage ofc)
<robimarko> Well, like I said it was open for a while
<jow> yeah sure, but that proves nothing
<jow> a plain wrong change that targets a fringe feature or target will likely also open for a while because noone looks or is interested
<jow> +be
<robimarko> I mean, how would have you dealt with this PR?
<jow> I would've lcosed it as providing no functional change with regression potnetial
<robimarko> It was open for a month, nobody commented on it and then somebody merged it
<jow> or would've likely ignored it until it rotted or got auto-closed at some point in the future
<stintel> so it breaks things, we revert it
<stintel> end of discussion ?
<jow> no, it seems we force ourselves fixing it now
<stintel> iirc this was discussed in some meeting, if something obviously breaks something, and cannot be fixed easily, just revert it
<jow> (metaphorical "we", I apprecaite the efforts you put into it)
<robimarko> stintel: I already posted a patch in the issue that should fix it
<robimarko> We just need somebody to test it
<jow> as did the original change :D
<stintel> but does the fix involve deviating from kernel's kconfig ?
<robimarko> It just reverts those 2 symbols to the previous state
<robimarko> As we were relying on deviating from KConfig
<robimarko> And until late 2019 that was fine until KConfig stopped writing the symbols that are not visible
<stintel> where is the fix ?
<robimarko> Its just a partial revert
<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> Unloading unused kernel modules (NAT speed)
<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> see - line 378 onwards
<dhewg> jow: iirc rpcd leaves "band" out if there's none set
<dhewg> 902mhz?
<dhewg> but luci already has something like "if(!band) continue", so those should just not show up
<dhewg> because it has a known list of bands anyway and puts channel in the band array as children
<jow> dhewg: looks like false alarm, I reloaded cfg80211.ko with ieee80211_regdom=DE and now I do see proper 6GHz band entries
<jow> the < 1000MHz stuff was indeed present and also reported by "iw"
<jow> along with negative channel numbers
<dhewg> alright, but what's 902mhz? is that the new low freq high speed thing?
<jow> totally no idea
<dhewg> hehe ok
<dhewg> wrt the user's comments, maybe he's confusing wifi6 with 6g? obviously you need 6e for 6gz, wifi6 often means just ax on 5ghz
<jow> that's how "iw phy0 info" reported it:
<dhewg> marketing \o/
<jow> okay, iwinfo/iw output is fine now, but LuCI broke
<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 binary, and I think upgrading the rpcd package does that? so ignoring manually messing around it should be fine
<dhewg> @NL80211_BAND_S1GHZ: around 900MHz, supported by S1G PHYs
<dhewg> I guess it's that
<jow> as if it is keeping some state
<dhewg> maybe the insmod didn't trigger the netifd hotplug thing?
<jow> netifd hotplug thing?
<jow> I didn't restart netifd, only rpcd
<dhewg> iirc netifd is responsible to setup radios as they come available?
<dhewg> may not be related, but that log looks weird indeed
<jow> now I can't reproduce it anymore... sight
<dhewg> iwinfo doesn't cache anything in that regard fwiw
<jow> I know
<jow> well, heisenbug
<jow> it all seems to work now
<rmilecki> if I can get back to qos for a moment
<rmilecki> I added debugging to kmodloader
<rmilecki> it seems /etc/init.d/qos restart does following:
<rmilecki> modprobe -r ifb
<rmilecki> modprobe ifb numifbs=1
<rmilecki> then modprobe of: cls_u32 em_u32 act_connmark act_mirred sch_ingress cls_fw sch_hfsc xt_multiport xt_connmark xt_length cls_u32 em_u32 act_connmark act_mirred sch_ingress cls_fw sch_hfsc xt_multiport xt_connmark xt_length
<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.
<stintel> rmilecki: this produces notrack rules with firewall4
<rmilecki> stintel: thank you, I'm taking a break now, i will report later
* f00b4r0 has to run too, bbl
dangole has joined #openwrt-devel
<stintel> looks like my m200 might still have an image with firewall3/iptables
<stintel> network doesn't work there but doesn't really matter to test this
<stintel> hmmm
<stintel> it doesn't have the iptables binary
<rmilecki> last note: even if i DON'T remove package/network/utils/iptables/patches/102-iptables-disable-modprobe.patch
<rmilecki> it seems that /etc/init.d/qos restart results in calling all those modprobe-s
<rmilecki> jow: ^^
<rmilecki> i don't understand iptables ;)
<rmilecki> ok, i'm running now
<rmilecki> comments welcomed, will just read them later
<stintel> rmilecki: qos-scripts /usr/lib/qos/ runs insmod
<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.
<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
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
<tmn505> karlp: mimic the commit by Zhou: to hide those errors
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
bluew has quit [Quit: Leaving]
bluew has joined #openwrt-devel
<owrt-2203-builds> Build [#237]( of `at91/sama5` completed successfully.
matoro has quit [Quit: ZNC 1.8.2 -]
matoro has joined #openwrt-devel
gladiac has joined #openwrt-devel
dangole has joined #openwrt-devel
<KGB-2> has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Borromini has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
Borromini has quit [Quit: Lost terminal]
shibboleth has joined #openwrt-devel
Slimey_ has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<dangole> i'd appreciate if someone with more experience in writing dt-bindings in yaml could take a look here:
goliath has quit [Quit: SIGSEGV]
cbeznea has quit [Quit: Leaving.]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<owrt-2102-builds> Build [#60]( of `rockchip/armv8` failed.
shibboleth has quit [Quit: shibboleth]
Slimey has quit [Ping timeout: 480 seconds]
cmonroe_ has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
Slimey has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
Slimey has quit [Read error: No route to host]
Slimey has joined #openwrt-devel
Lynx- has joined #openwrt-devel
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
<stintel> hmmm, dpaa/fman conversion to phylink in 6.2
<stintel> I sense some future m300 breakage :P
Obi-Wan- has quit [Remote host closed the connection]
Obi-Wan has joined #openwrt-devel
SamantazFox__ has joined #openwrt-devel
T-Bone has joined #openwrt-devel
<stintel> pfft, I'm starting to lose my patience with this damn M200
SamantazFox_ has quit [Ping timeout: 480 seconds]
f00b4r0 has quit [Ping timeout: 480 seconds]
Slimey_ has joined #openwrt-devel
Slimey has quit [Read error: No route to host]
Slimey_ is now known as Slimey
gladiac has quit [Quit: k thx bye]
zer0def has quit [Remote host closed the connection]
zer0def has joined #openwrt-devel
<KGB-2> has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
<hauke> nick[m]12: I think the biggest blocker for the next release are the bugs which are blocking the migration to kernel 5.15
<hauke> nick[m]12: I think ramips and lantiq still have some problems
Slimey_ has joined #openwrt-devel
Slimey has quit [Read error: Connection reset by peer]
Slimey_ is now known as Slimey