maxmadzz has quit [Read error: Connection reset by peer]
maxmadzz has joined #openwrt-devel
winternull_ has quit [Quit: Leaving]
<maxmadzz>
how to specify compiler？
danitool has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
MaxSoniX has joined #openwrt-devel
csrf has quit [Ping timeout: 480 seconds]
MaxSoniX has quit [Quit: Konversation terminated!]
maxmadzz has quit [Read error: Connection reset by peer]
maxmadzz has joined #openwrt-devel
srslypascal is now known as Guest1930
srslypascal has joined #openwrt-devel
Guest1930 has quit [Ping timeout: 480 seconds]
<ynezz>
jow: indeed, those cmake version bumps are that much annoying, that I was thinking about introducing CMAKE_VERSION config option :P
schwicht has quit [Read error: Connection reset by peer]
valku has quit [Quit: valku]
<Mangix>
ynezz: I assume your position regarding using meson for libubox/uibus, etc... is the same as jow's
Misanthropos has quit [Remote host closed the connection]
Misanthropos has joined #openwrt-devel
boxguy has quit [Quit: Page closed]
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
<ynezz>
Mangix: we can't drop CMake, thus it would mean, that we would need to support both (CMake and Meson) build systems, so this means additional overhead
<ynezz>
so I'm wondering which killer Meson feature would offset that overhead?
<ynezz>
lets see how this pans out, if Meson gains traction, then I think, that supporting both build systems would be inevitable
<ynezz>
in other words, I think, that nobody would object against adding meson build support, but you would need probably a good reason to convince someone to merge it
<svanheule>
xdarklight: that PR also fixes an issue with irq cpu affinity. I think the SoC interrupt controller you're working with is similar, with a separate SoC IRQ controller per CPU/VPE
knuxify has joined #openwrt-devel
<f00b4r0>
<ynezz> I really don't think, that it's a good idea to have Python based build system -- +1
aiyion has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
<fpsusername[m]>
Harm__: I think that the new master branch compiles the kpn extender, although it's still compiling for me, currently `tools/make-ext4fs compile`
<f00b4r0>
Mangix: reasons abound. To name a few: extra dependency in the system, when python breaks (or the tool requires a version of python you may not have on host) your build system breaks, extra overhead. I can go on. And I see no compelling "killer feature" to offset any of that
<f00b4r0>
the gitignore thing is a gimmick and can probably be implemented differently
<f00b4r0>
(assuming it's absolutely necessary)
<Mangix>
Uhhh, what?
GNUmoon has quit [Ping timeout: 480 seconds]
<Mangix>
Anyway, probably unlike cmake, meson is very careful to warn about features used in newer versions that would break on older ones. I don't see how the gitignore thing is a gimmick. It's very useful.
<jow>
one caveat: an include path /etc/firewall.user is treated specially
<jow>
it requires an additional `option fw4_compatible 1` otherwise it is ignored
<zorun>
is there a default include path?
<jow>
for all other paths, this option is implicitely set to `1`
<jow>
then there's config include; option type nftables; option position ...; option path
<jow>
this allows including raw nftables snippets instead of scripts
<jow>
option position is one of: https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/usr/share/ucode/fw4.uc;h=85456c9fde0005403433dedfa6aeb7f1242ba790;hb=11256ff0374fb594e31b0a4e3857f3810ba2933d#l1493
<jow>
append is alias for postpend
<jow>
ruleset-pre is before table inet fw4 { ... }, ruleset-post is after table inet fw4 { ... }
<jow>
table-pre is before first chain in fw4 table, table-post after last vchain in fw4 table
<jow>
chain-pre is before first rule in $chain, chain-post after last rule in $chain
<jow>
$chain is specified by `option type chain` (only applicable to option position chain-pre/chain-post/chain-append)
<jow>
a third way to add includes is to place files in /usr/share/nftables.d/{ruleset-pre,ruleset-post,table-pre,table-post,chain-pre/$chain,chain-post/$chain}/*.nft
<jow>
this is meant for packages and other non-confiurable firewall integrations
<zorun>
so there's "option type nftables" and then "option type <chain>" where <chain> can be arbitrary?
<jow>
config include; option type nftables; option path ...; option position {ruleset-pre,ruleset-post,table-pre,table-post,chain-pre,chain-post} [, option chain ...]
<zorun>
ah, I see
<jow>
option chain depends on option position chain-pre || option position chain-post
<jow>
(enum values may be abbreviated, so table-pr = table-pre = table-prepend)
<rmilecki>
Mangix: for such changes I'd prefer dropping idea on mailing list, personally I'd prefer not to have to learn another building tool, aka I'm lazy ;)
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<zorun>
thanks, I'll write it up in the wiki
<rmilecki>
Mangix: as I just discovered it's Python based... i think it dislike it by another bit
<zorun>
jow: regarding migration for people having iptables-based scripts, it's supposed to be manual?
<jow>
zorun: yes
<zorun>
we can't expect scripts to work with the iptables-nft wrappers?
<rmilecki>
Mangix: i had too many issues with Python software breaking, installing dependencies
<jow>
zorun: maybe, maybe not
<jow>
zorun: alos luci does not yet uspport all fw4 options, more changes in this regard are expected for 22.03.1
<jow>
e.g. it doesn ot allow editing custom rules (/etc/firewall.user), it does not uspport masq6 or ipv6 port forwards
<zorun>
rmilecki: ^ that failure seems related to your recent nvmem backport
<rmilecki>
that's why I waited for tagging ;)
<zorun>
good call :)
<rmilecki>
zorun: thanks for pinging me
<zorun>
np, it's my openwrt day (that doesn't happen too often...)
<zorun>
jow: what's the difference between "fw4 print" and "nft list ruleset"?
<zorun>
can both be used to dump / restore nft state?
<zorun>
the structure is the same, I see small differences, and an additional `include "/etc/nftables.d/*.nft"` in fw4 print
<zorun>
jow: btw, does /etc/nftables.d/ also support the various subdirs you described under /usr/share/nftables.d/ ?
knuxify has quit [Quit: Leaving]
<jow>
zorun: no, /etc/nftables.d has a fixed include position before the first chain of fw4
<jow>
users found it too inflexible for some scenarios
<jow>
it might be a good idea to make it support those same subdirs though. I'll consider that for .1
<jow>
fw4 print shows what is piped to nftables
<jow>
while nft list ruleset dumps the effectively rendered set
<jow>
the former will show what files are included while the latter shows everything lumped together, regardless of whether it came from fw4, an include or was added externally/manually through nft commands
<zorun>
ah, right, it makes sense
<jow>
bbl, need to scrape a dead animal out of the engine compartment
<zorun>
ok :D good luck
<Harm__>
fpsusername[m]: I've updated my fork. builds fine here
<hanetzer>
Mangix: hey, about meson. what packages in owrt build using meson? need some test cases.
Misanthropos has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
<Ansuel>
Hi
<fpsusername[m]>
<Harm__> "fpsusername: I've updated my..." <- It failed on `stats.c:110:59: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'time_t' {aka 'long long int'} [-Werror=format=]` where it treats a warning as an error. Not sure how to disable that. Will try your updated fork now. Seems like you also applied the phy patch on the master branch now
<Harm__>
yes, the same way as I submitted to the mailing list
<Harm__>
fpsusername[m]: in what package do you get that error?
<fpsusername[m]>
Package xdp-tools-1.2.5
<fpsusername[m]>
* Package `xdp-tools-1.2.5`
<Harm__>
fpsusername[m]: ah, I'm not compiling anything xdp related
<fpsusername[m]>
I'm not sure which package it is that enables it on my end
<Harm__>
look in menuconfig
robimarko has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
robimarko has joined #openwrt-devel
<fpsusername[m]>
No idea where to look in menuconfig. The search function isn't too easy to understand
<fpsusername[m]>
I think I only added some LuCi apps
<Harm__>
fpsusername[m]: so what if you unset things like xdp-filter, xdp-loader, xdpdump, libxdp in menuconfig?
<Harm__>
(prefixed by PACKAGE_)
<fpsusername[m]>
will try
<hanetzer>
so. some initial testing and hacking up the build system's python handling shows that `python -m venv staging_dir/host/` and pip installing into that (using the pip from the venv created by the prior command) solves some issues wrt u-boot's binman command
srslypascal has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
wow that mediawiki wysiwyg editor is beyond useless
* hanetzer
is more of markdown kinda guy
<stintel>
hipster ;p
philipp64 has joined #openwrt-devel
<stintel>
but yeah markdown is nice
<hanetzer>
if its any consolation I use latexx for documenting
<stintel>
at least you are documenting ;)
<hanetzer>
well, it depends. I mean non-tech documentation :P
<stintel>
:(
<hanetzer>
I don't generally do things that require docs (I rarely originate projects, just contribute to existing ones)
<stintel>
well some existing projects badly require docs ;)
<stintel>
contribute those! :P
<hanetzer>
true.
<stintel>
f00b4r0: thanks for adding the watchdog bits to m300 page
<stintel>
I just added some short install instructions as there were some very confused messages in the forum
<stintel>
well, mostly linked to the commits
<hanetzer>
so, thoughts on moving into a venv-based python management system for owrt's build system?
<stintel>
no opinion
<stintel>
maybe start a discussion in the ML or do an RFC patch if it's not too much effort
* stintel
sysupgrades his m300s - fingers crossed miniupnpd will still work
<stintel>
and I really need to fix conntrackd, TCP connections do not survive failover anymore :(
<hanetzer>
as of right now the only core python-based tool/etc is meson; I'm thinking to promote binman (from u-boot) into a tools/ entry
<stintel>
iirc earlier people expressed their dislike for python-based build stuff in here
<hanetzer>
well, for building u-boot for some arm boards its getting harder and harder to not invoke python during build
<hanetzer>
eg, binman, dtoc/of-platdata stuff, and so on
srslypascal has joined #openwrt-devel
<robimarko>
f00b4r0: Looks like AFM doesnt really work properly with multicast
<robimarko>
It parses MIB 281 correctly, but not 309
<robimarko>
And I cannot find a way to enable IGMP snooping so it stops just forwarding multicast
<hanetzer>
that being said. you know how the owrt linux kernel has a set of common to all platforms patches and a set of platform specfic ones? is it possible to do the same for say u-boot?
dangole has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
<Ansuel>
hanetzer i guess it can be done... just some magic in the makefile
<Ansuel>
we have something like that for mac80211
<Ansuel>
(multiple dir for patches)
<f00b4r0>
stintel: yes it's beyond useless and yw and I'm trying to load your changes but the wiki doesn't load for me :)
<f00b4r0>
oh yes it does. Unbelievably slowly
<stintel>
we really need to come up with a replacement for that hacked together piece of crap :P
<f00b4r0>
robimarko: i see. Maybe it should be documented on hack-gpon. I've been meaning to make some changes there until I realised it's not a wiki ;P
Tapper has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<f00b4r0>
robimarko: btw, weren't you playing with the RB5009? Have you given up?
<fpsusername[m]>
Harm__: please give me your config, unless, well, you use the default config and enabled LuCi
minimal has joined #openwrt-devel
Borromini has joined #openwrt-devel
<robimarko>
f00b4r0: Well, that the SFP they are using with working multicast
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #openwrt-devel
<robimarko>
But, I have not been able to find anybody on their Telegram group who can confirm that or provide example IGMP proxy
<robimarko>
Seems like they are using it that way
<robimarko>
Yeah, I did the initial work on RB5009
<robimarko>
But, lack of time killed that
<robimarko>
Also, U-boot appeared to be corrupting NAND if writing or something like that
<robimarko>
These GPON ONU-s are so much pain, every single one is half-assed and does not suport XYZ
<robimarko>
Have the DT/Zyxel arriving tommorow, will give that one a go and see if it supports IGMP snooping
<robimarko>
Its 2.5G also unlike 1G AFM
<Borromini>
robimarko: any chance you'll get to have another look at the QCA8081 on the RB5009UG? 👼
<robimarko>
Borromini: Like all of the other things, its on the long TODO list
<Borromini>
:)
<robimarko>
I dont think QCA8081 is to blame, it looks to be a MVPP2 issue
<Borromini>
ok
<robimarko>
*Not MVPP2
<robimarko>
Marvell DSA driver
<robimarko>
I will probably get it working under Buildroot on a fresh kernel as the driver saw tons of fixes
<robimarko>
But, currently I am trying to finalize IPQ807x and make a PR for that
<Borromini>
you mean higher than 5.15?
<robimarko>
Yeah, probably current RC or linux-next
<Borromini>
ok.
dangole has quit [Remote host closed the connection]
<robimarko>
f004br0: Web UI for AFM has way more stuff in the source
<robimarko>
Including bridge mode, PPoE, IGMP etc
Ansuel has quit [Read error: Connection reset by peer]
<robimarko>
Its just hidden somehow
guerby has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Ansuel>
robimarko any problem with ipq807x ? or is the sysupgrade one the real blocker?
<Mangix>
hanetzer: git grep meson.mk
<Mangix>
rmilecki: meson is sort of a compiled python program. That's not an issue.
<Mangix>
In any case, I'm asking on IRC as stuff I submit on the mailing list (patches) typically go nowhere.
cbeznea has joined #openwrt-devel
<f00b4r0>
robimarko: interesting. You will likely find the zyxel web rather /bare/, but on the commandline it seems pretty featureful
<f00b4r0>
and it's running OpenWrt, so there's nothing we shouldn't be able to fix ;)
<f00b4r0>
i'm gonna try to snatch a couple more, I'll get in touch with the seller tomorrow
<hanetzer>
Ansuel: I suppose that's only possible because mac80211 is one dir, unlike say, packages/boot/uboot-{envtools,sunxi,rockchip,...} yeh?
<Ansuel>
ok yes that is problematic
<Ansuel>
problem is that in such implementation every tweak to have a generic dir would be an hack
<Ansuel>
we should change the logic and have every target specific package in one uboot directory that way it should be cleaner but still it's a mess to fix it
<hanetzer>
Ansuel: reason being, depending on how this venv/binman/etc stuff turns out it *may* be needed to pach the makefile for u-boot to not try to use binman in-tree
<Ansuel>
so we will have to have a patch that will be present in each uboot-target package
<hanetzer>
yeah, which is a bit annoying
<Ansuel>
having a generic patch directory is doable... problem is how to make it less messy
<Harm__>
hehe, I recently got 3x Experia WiFi on marktplaats for €17 including shipping :D
<Habbie>
oh neat :)
<Habbie>
i honestly don't know where my experia wifi is
<Habbie>
so i still haven't tested your build or even your uboot patch
<Harm__>
:(
<Habbie>
i'll find it under four newer projects once i finish those, i have no doubt
<Harm__>
haha
<Habbie>
one of which is yet -another- dutch router, a zyxel with online.nl sticker
<robimarko>
Ansuel: sysupgrade is the biggest blocker
<robimarko>
f00b4r0: I dont really care about the web UI if CLI has all of the features
<robimarko>
As long it properly supports G.988 thats fine for me
<robimarko>
And allows changing SN and vendor obviously
<robimarko>
It is supposedly arriving tommorow, so I will give it a go
<robimarko>
Hopefully IGMP works
<Ansuel>
(manage to port all the split patch to 5.15)
clayface has joined #openwrt-devel
<hanetzer>
Mangix: I swear that turned up nothing last time I tried it xd
<hanetzer>
yeah, its a bit like those binary sh scripts you may get from various vendors
clayface_ has quit [Ping timeout: 480 seconds]
csrf has joined #openwrt-devel
MaxSoniX has quit [Quit: Konversation terminated!]
<Mangix>
hanetzer: where are ypu searching?
<fpsusername[m]>
<Habbie> "Harm__, fpsusername, i found a..." <- Cheap asf. OpenWRT on the new extenders as a next project?
<hanetzer>
I was maybe thinking of folding tools/binman under tools/mkimage; they are fairly frequently used together
<hanetzer>
Mangix: I may have been in a feeds repo
<Habbie>
fpsusername[m], yep, on the list, some day
<Mangix>
both base and packages have meson packages
<Mangix>
telephony and routing probably not
<fpsusername[m]>
Habbie: Well, with the experience we got from the old extender, the new extender shouldn't be too difficult
<hanetzer>
yeh. either way, I musta goofed somehow.
<fpsusername[m]>
uboot passwords are no problem with reflashing a modified uboot
<Habbie>
fpsusername[m], this one is older, and i don't know how related they are - this one is a broadcom, not a mediatek i think
<Habbie>
fpsusername[m], but i'll report back, some day
<fpsusername[m]>
Ooh
<fpsusername[m]>
I thought they were newer
<Harm__>
Broadcom isn't that great for OSS
<Habbie>
i could be wrong
<Habbie>
Harm__, yeah i read that
<fpsusername[m]>
Because I know the black ones we have are the second last on the market iirc
<Borromini>
Broadcom is crap
<Borromini>
if it's 2,5 €... sure. but don't bother with OpenWrt unless it has very specific supported radios (and even then it's still binary blobs)
<Habbie>
Borromini, honestly these 2-5 EUR finds are just boxes to toy with and learn a few things, either about bootloaders, or porting openwrt, or whatever
<Habbie>
they might never hit production here
<Borromini>
ok :)
<Habbie>
the zyxel, for example, once ported, to me is just a mips24kc box with more flash/ram than the one i sometimes develop things for ;)
<Habbie>
in which case the radios don't matter
<hanetzer>
fpsusername[m]: well, unless they've fused some things in the soc :P
<Borromini>
Habbie: cool :)
<Harm__>
I won't spend time on it myself. This experia wifi was a nice learning experience and I've got plenty of AC access points now ;)
<Habbie>
:)
<fpsusername[m]>
hanetzer: I still assume that the flash is separated. The only thing increasing difficulty would be CRC checks and what not
<hanetzer>
fpsusername[m]: some socs are capable of blowing fuses inside themselves to force a 'secure boot'; hell one of the ones I'm currently fucking with can fuse a password onto jtag access
<robimarko>
hanetzer: Unfortunately, all of the modern ones can do that
<hanetzer>
yee.
<hanetzer>
doesn't mean it *has* been done, but something to be careful of
<robimarko>
Yeah
<hanetzer>
makefile: bashisms, yey or neah?
<robimarko>
Some vendors really abused that
<robimarko>
Meraki really liked pushed updates to force secure boot
<robimarko>
And brick peoples boards
<hanetzer>
can't have them becoming valuable aftermarket devices without contract now can we?
<robimarko>
Yeah, gotta keep that sweet licensing money to use your HW
<hanetzer>
meraki mr24's were solid devices for a while. I got em for a very nice price too ($10USD each)
<Borromini>
was that before or after Cisco acquired them?
<hanetzer>
honestly no idea.
robimarko has quit [Quit: Leaving]
<Borromini>
was just curious :)
<hanetzer>
only thing that's *really* ass about them is you have to crack them open to do the initial flash, and cracking them open, while very nondestructive, is annoying.
<Borromini>
:)
<hanetzer>
like, 6 star screws and four phillips
<hanetzer>
and a bit of prying to get the first layer off
<hanetzer>
you'd have to be incredible hulk manhandling them to break them while opening them, but that's about it.
<fpsusername[m]>
<hanetzer> "fpsusername: some socs are..." <- yes, but would they really use those on consumer products? I mean, most don't do it
<hanetzer>
so yeh. are we strictly limited to 'sh' in makefiles or can one use bashisms? I know gnu bash is required for building, but I've seen SHELL=sh in a place or two
<Borromini>
hanetzer: i don't think bash is a requirement and some devs build on MacOS e.g.
<Mangix>
Borromini: bash is absolutely a requirement
<oliv3r[m][m]>
Borromini I use the openwrtorg docker container, which works good enough :)
<oliv3r[m][m]>
I'm struggling to wrap my head around this whole DSA business, and since switch support (the realtek ones) is quite new, I'm not sure what to expect. I have each LAN port exposed as a device as per DSA guideline. However, the switch is not 'switching' traffic by default. Is this expected? I have a device called 'switch.1' which probably is the 'CPU' port, which IS getting its IP address via DHCP via any of the ports; sot hat bit
<oliv3r[m][m]>
works. But plugging in a second device (usb eth) to, lets say port 3, the host can't get a DCHP reply. So it seems only the CPU port is getting traffic. Is this expected?
<hanetzer>
how do you make tools/meson/{clean,hostinstall}? is it hostinstall?
<Mangix>
hanetzer: no just install
<Mangix>
you looking to time it or something?
<hanetzer>
nah, just tweaking it and want to rebuild. clean,install gave no rule for install tho
<hanetzer>
either way, a few of those tools/ packages use meson to build so a full tools/{clean,install} tests more than just whatever the right invocation for meson is.
<hanetzer>
well, that works :)
<hanetzer>
for reference: $(STAGING_DIR_HOST) was made into a venv, and meson, instead of doing that zipscript thing, was pip installed into it, and zstd/pkgconf were built and installed fine
<hanetzer>
(the latter just needed a change to meson.mk to use $(STAGING_DIR_HOST)/bin/meson instead of meson.py)
<Mangix>
no idea what venv is
<Mangix>
IIRC adding the .py extension is necessary to fix compilation with the SDK
<Mangix>
create_zipapp.py is used to avoid a dependency on host pip
<hanetzer>
venv=virtualenv. its a default python module to be frank I have no idea if distros that split off python and pip ship with that to begin with
<Habbie>
debian (used to?) split it off
<Mangix>
probably still does. why buiild meson with that?
<dwfreed>
the venv module (python3 -m venv) on debian bullseye is in the stdlib python package
<dwfreed>
python3.9-venv still exists as a package, just only provides pyvenv script, which is deprecated anyway
<hanetzer>
mostly a PoC test, I don't intend to change meson
<hanetzer>
worst case, one could just setup.py install without pip
<hanetzer>
question. I want to patch uboot-sunxi to use a tool from $(STAGING_DIR_HOST) instead of in-tree; this is something that will *never* be upstreamed, and I'm not sure which Nxx number I should slap it into
<hanetzer>
Mangix: as mentioned, its just a PoC; I just needed something snake-flavoured to test with :)
<hanetzer>
why do we need distutils anyway?
<hanetzer>
ugh. package/boot/uboot-sunxi/update V=s clobbered my patch
<zorun>
jow: also, I noticed that fw4 is a bit slow to build the rules, is that on your radar?
<zorun>
it takes 2 seconds on a ipq40xx which is supposedly fast hardware
<jow>
zorun: not yet. I commonly test on apus, er-x's and mir3g
<jow>
right now it's about ~900ms on my er-x
<jow>
I'm not too worried about it though. Since nft does atomic ruleset replacements on firewall reload (not restart!) the processing time doesn ot matter much
<jow>
restart time coulle be cut in half with some tempfile caching
<jow>
right now it renders the ruleset twice; once for checking, once for applying
<zorun>
"fw4 print" already takes 1.76s
<zorun>
fw4 reload = 2.08s
<zorun>
fw4 check = 2.04s
<zorun>
fw4 restart = 4.06s
<jow>
yeah, seems rather slow
<stintel>
I wouldn't call ipq4*** fast
<jow>
I only ever tested on x86 and mt7621 based hw
<jow>
and there it's consistently between ~900ms and 1.2s
<jow>
it won't get as fast as fw3 but there's some untapped optimization potential
<stintel>
my uci config generates a 1019 line nft ruleset - real 0m 1.25s on m300
<stintel>
1.5GHz PPC64
<stintel>
I'd call it reasonable ?
<jow>
do you think it is a problem? At least from all the reports about fw4 so far, none was about it's rule rendering speed
<jow>
I guess it is in line with what one would epxect form a script based preprocessor
<stintel>
I've been testdriving firewall4 for a while now, never bothered me
<zorun>
ipq40xx is much faster than old ar71xx :) but ok, that's not as fast as other hardware
<zorun>
jow: yes, I was just a bit surprised about it while doing several edit - reload rounds
<zorun>
not a big deal
<jow>
I do plan some improvements for .1
<zorun>
great
<jow>
we could also consider precompiling all the scritps into one big lump, that usually shaves of 25-45% of the overall runtime as well
<stintel>
mostly curious how many new bugreports we will see now that 22.03 is almost built
<hanetzer>
heh
<jow>
maybe also do some profiling to see where time is actually spent, we do call nft a few times under the hood to gather info, maybe the nft call overhead is significant too
<stintel>
tested the latest miniupnpd bump, it didn't work on boot, had to restart miniupnpd to make it work, and rules are still duplicated 😂
<Mangix>
it's been brought to my attention that I should be using mediatek,nmbm for this device
<Mangix>
seems like arcanery
<stintel>
what arcanery ?
<jow>
stintel: too bad, I thought it has been sorted out by now
<jow>
I refrained from spending time on it since I though it's been taken care of by one of the various PRs
<jow>
zorun: yeah, expected. we need to profile it, see if we can improve the performance
<Mangix>
initially I thought mediatek,bbt was supposed to be used
<Mangix>
nope
<stintel>
depends on the device
<stintel>
usually u-boot gives you hints
<zorun>
jow: btw, if the 2s-delay is the only gripe I have with fw4, it probably means that the rest is working fine :)
<Mangix>
stintel: I got the hint from the open source tarball for these devices
<hauke>
The 22.03 build finished today in the morning, I am too tired to send the mails out today, will to it on Monday evening
<zorun>
hauke: I checked the release notes, I added a link to the new fw4 documentation about custom rules. The rest looks fine (but I haven't followed closely what happened in 22.03)
<hauke>
zorun: thanks for the update
<jow>
hauke: wise decision
<stintel>
hauke: thanks for all the effort on 22.03
<zorun>
+1
<jow>
hauke: and maybe send it to contact@ first for proof reading
* Mangix
grabs popcorn
<hauke>
jow: ok
philipp64 has quit [Read error: Connection reset by peer]
dangole has joined #openwrt-devel
<Mangix>
hmm I take it the Unifi 6 LR is the only 2.5gbps device supported by openwrt?
<stintel>
MACCHIATObin maybe
<stintel>
once ipq807x lands probably several more
<Mangix>
oh interesting
<stintel>
not succeeding in booting the OpenWrt kernel on BSAP3040 :(
<stintel>
that's also 2.5GbE iirc
<Mangix>
what platform is that?
<stintel>
qoriq
<Mangix>
just merged a mariadb fix for that.
<stintel>
and I thought I ran weird things on my routers 😂
<hanetzer>
my openwrt devices aren't even routers :)
<Mangix>
i really need to liquidate some of mine.
<stintel>
I'm having an attempt to have an OpenWrt minik8s os with k3s
<stintel>
but I'm failing to build rancher-plugins
<stintel>
golang is annoying AF to package
<stintel>
I'd use k3os but it appears to be abandoned
<Mangix>
yes. it also only supports x86
<stintel>
huh?
<Mangix>
the HostBuild
<stintel>
that's an OpenWrt specific thing then
<Mangix>
I tried to build it on an m1 mac. No dice.
<stintel>
I'm happily using go on ppc64
<stintel>
well maybe not happily, it's still annoying to package :P