<lipnitsk>
mangix: did you mean to create a new patch within the patch or something?
<dangole>
mangix: thank you, good catch
<dangole>
anyone got an idea how i can force the steps in `Device/Build` in include/image.mk to happen sequential instead of in parallel?
<dangole>
because like now all images and artifacts are created in parallel, which sucks because you can't reference images in artifacts or use preceding artifacts in following ones
<lipnitsk>
dependencies somehow? create temp .stamp files or whatever to indicate rule completion?
<dangole>
I do understand how to do that in a "normal" Makefile, but I don't get how it could work in image.mk in OpenWrt with all the level of indirection piled on top of Make
<dangole>
hmmm, maybe we really need a third thing. IMAGES, ARTIFACTS and maybe call it ASSEMBLIES (?) for things potentially assembled from IMAGES and ARTIFACTS, ie. runs after the both have completed.
<mangix>
aparcar[m]: pong
<mangix>
lipnitsk: there's no other place to propose patches for procd
<lipnitsk>
yeah I figured. sorry.
<mangix>
maybe private email
<rsalvaterra>
Speaking of procd… can we please merge my patches and kill tmp-on-zram with fire? :P
<guidosarducci>
rsalvaterra: thanks, that's similar to what I had. I'm trying to keep down to 2 variants, as each is a full blown package compile, and I felt pushing it when originally adding the tc variant.
<mangix>
rsalvaterra: what is this zram-swap?
<guidosarducci>
rsalvaterra: supporting shared libs only for tc-full is needed, so may need to use 4 variants in the end (yuck!)
<guidosarducci>
rsalvaterra: I'll share something after a bit of juggling...
<rsalvaterra>
mangix: It's an obsolete procd feature which allows you to directly mount /tmp on a zram block device. Useless and redundant, since we have zram-swap and tmpfs is backed by anonymous memory.
<rsalvaterra>
guidosarducci: I haven't tested if building a statically linked tc(-tiny) will make a huge difference, yes.
<mangix>
description says A script to activate swaping on a compressed zram partition.
<mangix>
so this is an alternative to a normal swap partition?
<rsalvaterra>
mangix: I'm not talking about zram-swap.
<rsalvaterra>
Mine is a bit different because I also factor in the expected compression ratio when defining the device size. I haven't sent this upstream because I don't feel like dealing with the changes LuCI requires. :P
<rsalvaterra>
Off to bed now. Cheers!
<guidosarducci>
rsalvaterra: 'night
dangole has quit [Remote host closed the connection]
luke-jr has quit [Ping timeout: 264 seconds]
opal has quit [Ping timeout: 268 seconds]
Tapper has quit [Ping timeout: 245 seconds]
luke-jr has joined #openwrt-devel
victhor has quit [Ping timeout: 264 seconds]
opal has joined #openwrt-devel
hbug_ has joined #openwrt-devel
hbug has quit [Ping timeout: 268 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
black_ant has quit [Ping timeout: 245 seconds]
swegener has quit [Ping timeout: 272 seconds]
ldir- has quit [Read error: Connection reset by peer]
ldir has joined #openwrt-devel
swegener has joined #openwrt-devel
<hurricos>
is it possible to successfully spawn pppd from a console? o_e
<hurricos>
I've tried exec + removing askconsole from the inittab but no dice
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
silverwhitefish has joined #openwrt-devel
opal has quit [Ping timeout: 268 seconds]
pine127_ has quit [Ping timeout: 268 seconds]
hbug_ has quit [Ping timeout: 268 seconds]
owrt-snap-builds has quit [Ping timeout: 265 seconds]
DLange has quit [Ping timeout: 272 seconds]
owrt-1907-builds has quit [Ping timeout: 265 seconds]
guidosarducci has quit [Ping timeout: 268 seconds]
koniu has quit [Ping timeout: 268 seconds]
owrt-2102-builds has quit [Ping timeout: 256 seconds]
kontaxis has quit [Ping timeout: 268 seconds]
tobleminer-tSYS has quit [Ping timeout: 264 seconds]
<owrt-snap-builds>
build #688 of octeon/generic is complete: Failure [failed targetupload] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/688 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
<owrt-2102-builds>
<paweldembicki@gmail.com>
<owrt-2102-builds>
build #14 of ath79/generic is complete: Failure [failed targetupload] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ath79%2Fgeneric/builds/14 blamelist: Rui Salvaterra <rsalvaterra@gmail.com>, Georgi Valkov <gvalkov@abv.bg>, Ronny Kotzschmar <ro.ok@me.com>, Stefan Lippers-Hollmann <s.l-h@gmx.de>, Pawel Dembicki
pine127 has joined #openwrt-devel
opal has joined #openwrt-devel
koniu has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
kontaxis has joined #openwrt-devel
hbug_ has joined #openwrt-devel
<Grommish>
For the package folks.. Usig PKG_INSTALL = 1 should call make install after the first make, correct?
cirfis has joined #openwrt-devel
cirfis5 has joined #openwrt-devel
<damex>
Grommish: when did you start having a packet loss on your itus shield? after 5.10 or after cn63xx errata patch merge?
<damex>
because on 5.4 it was tested to be working fine.
<Grommish>
damex: I never had a working 5.10 version
<Grommish>
I get the same ehci kernel panic Borromini gets on the ERLite
<Grommish>
I've not had time to test anything further because dnsmasq is being stupid
cirfis has quit [Quit: Connection closed]
cirfis5 is now known as cirfis
<Grommish>
damex: I'm working on a SysBench package to run benchies between versions though
<ynezz>
nbd_: 0a497c4640a05bafa is probably causing issues when building packages with SDK and out of tree as there is -DABIVERSION="" which then results in install: cannot stat 'libubox-2020-12-12-35787769/ipkg-install/usr/lib/libubox.so.*': No such file or directory
<ynezz>
I've now scheduled daily builds (in addition to after push builds) for all projects which have CI support, in order to catch those regressions sooner next time
<jow>
or, slightly cleaner: PKG_ABI_VERSION ?= 0 somewhere at the top of the Makefile
<jow>
but maybe I confused something... what do you mean with "SDK and out of tree" exactly? Does that mean that the ABI version mechanism does not properly work for SDK built packages?
<Borromini>
the 'completely untested' sounds extremely tempting ;)
<rsalvaterra>
Borromini: Heh… they're not exactly earth-shattering changes… :P
<Grommish>
rsalvaterra: the last time you said that it invoved gutting ssl ;p
<Borromini>
xD
<jow>
my motivation to merge untested commits is zero, as I personally lack the time
<ynezz>
jow: CI uses Docker SDK containers, so for example openwrtorg/sdk:ath79-generic-master and creates CMake toolchain file https://gitlab.com/ynezz/openwrt-ci/-/blob/master/openwrt-ci/sdk-build.mk#L12 so it can then build package out of tree, usually checked out by CI in /builds/openwrt/project/libubox directory having SDK unpacked in /home/build/openwrt
<rsalvaterra>
Grommish: But the OpenSSL axe murder is fully tested (and running) on my machines. ;)
<Grommish>
rsalvaterra: Oh, well, nevermind then
<ynezz>
jow: so the only difference between native (host) and target (SDK) is CMake's toolchain file
<jow>
ynezz: ah ok, I understand
<ynezz>
jow: this out of tree builds usually expose different kind of CMake issues as well, hardcoded/implicit stuff etc.
<rsalvaterra>
jow: I fully accept and understand. The idea was just to get it out there, someone interested will probably test it. ;)
<Grommish>
rsalvaterra: I'll leave it up and mess with it tomorrow if you'd like
<rsalvaterra>
Grommish: If you use LuCI and zram-swap, that would be great, thanks! :)
<Grommish>
LuCI, yes, zRAM no.. no swap on the device
<Grommish>
I was going to ask about that ;p
<rsalvaterra>
Grommish: zram is a RAM-based compressed block device. The typical use case for it is to create a compressed swap partition in RAM.
<rsalvaterra>
(To be honest, I never saw it being use in a different way.)
<rsalvaterra>
Grommish: Come to think of it, you use Suricata, which has some really "interesting" memory requirements. It's probably a good idea for you to have zram-swap. ;)
<Grommish>
Oh? Hmm.. I'll have to check it out after I do this other thing
<Grommish>
and right now, Suricata isnt working. It won't find the pcap.h file ;/ I suspect it's an issue on their end and reported it. I can't imagine anyone trying to not use the host libs
<jow>
ynezz: another idea, maybe simply export PKG_ABI_VERSION=$(date +%Y%m%d) in your container?
Tapper has joined #openwrt-devel
plntyk has quit [Remote host closed the connection]
Borromini has quit [Ping timeout: 260 seconds]
plntyk has joined #openwrt-devel
<ynezz>
jow: yes, probably something like that if it's expexted and WONTFIX :)
<ynezz>
s/expexted/expected/
<russell-->
weird, i have an old soekris net4826 which is locking up during first boot, after a line that looks like this: [ 2.274158] Working around Cyrix MediaGX virtual DMA bugs.
<Grommish>
My device came in after it was broken, so I'm not sure what the effect it might have, however others have raised the issue it has bad things on the newer octeon targets
<Grommish>
at the expense of a single device that isn't maintained
<Grommish>
so.. I want to find out if and how much it effects things
<rsalvaterra>
Oooooh…!
* rsalvaterra
totally forgot he can now set vm.swappiness to 200, on Linux 5.10.
<Grommish>
rsalvaterra: You'd be proud, i had to rebuild the MS WSL kernel for modules :)
<rsalvaterra>
I build the kernel every week… :P
<Grommish>
and it still worked.. MS did a really decent job with WSL
<rsalvaterra>
Right now: Linux presler 5.12.0-rc1+ #78 SMP Mon Mar 1 11:59:23 WET 2021 x86_64 GNU/Linux
<Grommish>
Linux DESKTOP-N35LRJ4 5.10.17-microsoft-standard #4 SMP Wed Feb 24 23:27:58 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
<rsalvaterra>
Nice…! 5.10.17 on WSL? (I never used WSL.)
<Grommish>
Yeah WSLv2
<Grommish>
the WSLv2 kernel doesn't come with modules enabled and headers
<Grommish>
but, after that, it's been smooth.. once I limited the RAM it was eating
<rsalvaterra>
Not having modules sounds like a feature to me… ;)
<rsalvaterra>
Modules require core kernel exported symbols. Exported symbols are compiler optimisation barriers. Modules == less optimisation opportunities, especially as far as total kernel size is concerned.
swegener has quit [Changing host]
swegener has joined #openwrt-devel
* rsalvaterra
thoroughly despises compat for that very reason…
<jow>
Tapper: yes, for the majority of use cases you cna just replace the package
<jow>
config etc. remains identical
<Tapper>
Will there have to be changes to other packages like addblock and banip egeg
<jow>
no
<jow>
or rather, depends
<jow>
if they do firewall ops via ubus, then no
<Tapper>
Sounds good
<jow>
if they do manual iptables, then yes
<Tapper>
kk
<jow>
however iptables and nftables can coexists to some extent
<jow>
but it'd be a waste of space and hard to debug if things do not work
<Tapper>
What be the advantages of firewall 4 then?
<jow>
future proof
<jow>
iptables is being phased out and nowaday it is just a compatibility wrapper around iptables
* Tapper
nods
<jow>
*around nftables I mean
<Tapper>
kk thanks for your work on this then
<rsalvaterra>
jow: Future proof… until bpftables takes off, of course… ;)
<jow>
yeah
<jow>
well they opted for the virtual machine route, so in the end it's all just different language frontends
<jow>
which will be compiled to some low level matching vm
<rsalvaterra>
Somehow, that will require an eBPF compiler in the router itself… I can imagine the storage requirements skyrocketing in the near future.
valku has joined #openwrt-devel
<lipnitsk>
any opinion on squashing cherry-picks together in a 21.02 PR?
<lipnitsk>
yay, nay, doesn't matter?
<jow>
rsalvaterra: yes, and ebpf stuff in its current form is not really cross-compilable and requires the llvm framework to build elfs to upload to the kernel
<jow>
a different compiler frontend or a cross-compile toolchain will be needed
<jow>
the latter will make it impossible to change rules/filter programs on-target though
<rsalvaterra>
jow: That's going to be wonderful on 8 MiB devices. :)
<jow>
so either you write a generic ebpf program which you can somehow pass parameters to, like building a crappy variant of nftables
<jow>
or you build another compiler frontend which emits the necessary risc byte code and which does the ELF framing manually
<rsalvaterra>
jow: Or you generate your rules on the local machine and upload the ready-to-eat BPF bytecode to the router…
<jow>
yeah or that, but compared to plain text rules that is quite impractical
<jow>
requires a linux machine / docker container / sdk / webservice to compile opague binary blobs which you then load into the kernel
<jow>
does not really inspire confidence
<rsalvaterra>
Right, too convoluted for my taste.
<olmari>
Inquiry from the curious: is that said binary compiled FW ruleset then also more performant than plain text? :)
<jow>
sometime this year I want to take a stab at building an alternative compiler for ebpf
<rsalvaterra>
olmari: Insanely fast, according to some prototype benchmarks I've seen years ago.
<olmari>
In that case I can fully understand and see why... not that it "fits" too perfectly on openwrt general case of "all the small devices" in space requirement sense, but as perf... well... in general case personally I'll take the perf always :)
<rsalvaterra>
And comparing the performance of iptables and nftables, I can't see a compelling reason to switch to nftables.
gromero_ has joined #openwrt-devel
gromero has quit [Ping timeout: 276 seconds]
Night-Shade has joined #openwrt-devel
Night-Shade has quit [Client Quit]
<hurricos>
So what, rebuild the linux kernel network filtering stack to be more like how graphics work?
<hurricos>
everything precompiled jit? those'll be some fat libraries :|
rsalvaterra has quit [Read error: Connection reset by peer]
<jow>
hurricos: essentially, yes (bytecode/jit)
Tapper has quit [Ping timeout: 245 seconds]
rsalvaterra has joined #openwrt-devel
<hurricos>
christ, I'd love to imagine a world where OpenWrt could self-compile those at runtime and host different arch toolchains
<hurricos>
and you could have like, your cross-compiler running on an Openwrt Cavium manycore MIPS host and clients would reach out to it for new rulesets or fallback to native iptables
<hurricos>
but on the other hand, spend more than 4 seconds thinking about it and that looks so
<hurricos>
so so so bad
<hurricos>
I mean -- I'm all for completely software-driven implementations, but ... think of how frequently iptables rules can change in e.g. a routed mesh network
<hurricos>
or wait no.
<hurricos>
Well
<hurricos>
OK, the one thought there is that, maybe for bigger managed switches.
<hurricos>
Like, imagine if a vendor marks redistributable some switch ASIC binaries and now suddenly the P2020 whitebox switches are on the market
<hurricos>
P2020 is not a slow processor, and you get plenty of storage on those boards, and they have 10GBe interfaces -- and for those *sometimes* where you need to route stuff through the CPU, that's big gains
<hurricos>
but still, can't see the synergy with OpenWrt's main targets
repulse has joined #openwrt-devel
<hurricos>
also ONIE already has that market cornered
eduardas has quit [Quit: Konversation terminated!]
shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openwrt-devel
Tapper has joined #openwrt-devel
<blogic>
...
<blogic>
so today 2.3. i turned 42 ;P
<blogic>
been waiting for my 2342 day for decades
<blogic>
what are the odds on that one ....
<Redfoxmoon>
happy birthday:-)
<rsalvaterra>
blogic: Heh… I'll be 40 this year… :P Happy birthday! ;)
<blogic>
spent the day with my daughter building the big lego harry p[otter castle ;)
<rsalvaterra>
I miss the Lego (Technic) from my childhood… It's all very commercial, nowadays.
<blogic>
yeah
<blogic>
still was fun
shibboleth has quit [Quit: shibboleth]
zatwai has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
<Borromini>
thanks for the detective work on the ramips 5.10 PR btw
<lipnitsk>
haha, is that controlling the ML operations?
<Borromini>
no it's a site that offers you a sanity check :)
<lipnitsk>
yeah, good thing there are willing testers.
<lipnitsk>
No, I mean the infradead site
<Borromini>
infradead.org hosts the ML yes
<lipnitsk>
okay, so just resend when it's back up?
<Borromini>
it hosts multiple i think.
<lipnitsk>
or will it process the queue?
<Borromini>
yeah, probably
<lipnitsk>
i guess just wait and see
<Borromini>
i have no idea, sorry.
swex has quit [Quit: swex]
<Borromini>
you can ping dwmw2_gone i think he runs it/has access to it
<Borromini>
lipnitsk: is that XTAL_MASK 3 bits in 5.4 still btw? i looked for it but couldn't find it
<lipnitsk>
nah, its not even in 5.10
<lipnitsk>
oh i mean sorry
<lipnitsk>
I think it was just an issue on mainline
swex has joined #openwrt-devel
<lipnitsk>
I tried backporting the mainline to 5.10 and it backfired, but we found the bug as a result
<lipnitsk>
my PR just uses the staging version of the driver from 5.10 now with a small Kconfig change.
<Borromini>
ok so should be OK on 5.4? the commits you linked to in one of your comments, i sent in those patches adding explicit resets for the PCIe bus
<Borromini>
ok
<lipnitsk>
the reset issue is something else, I was confused
<lipnitsk>
resets may be misconfigured and that's fixed via device tree, but this was a driver bug.
<Borromini>
ok. i thought it was related going by what was said in the comments, but I know nothing about the code really.
<lipnitsk>
I know nothing about that code either, and Sergio was very helpful in patiently explaning it ;)
<lipnitsk>
I guess he got a bug fix and some testing out of it so he should be happy ;)
<Borromini>
yeah he is very helpful. he helped me troubleshoot that reset issue earlier as well (i had been running dengqf6's 5.10 ramips PR on a DIR-860L for a while)
<lipnitsk>
now if we can bisect the packet loss that would be great. I think the branch is pretty much ready to merge even now..
<Borromini>
:)
luke-jr has quit [Read error: Connection reset by peer]
<rsalvaterra>
Guys, is it possible to test DSA on ath79 devices already? :)
<lipnitsk>
I also started a thread on LKML about "BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1" and even got a response from Linus! Still investigating that one though, but that issue is pretty benign
<Borromini>
rsalvaterra: blocktrron has this but no idea about the state: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=shortlog;h=refs/heads/dsa-ar9344
luke-jr has joined #openwrt-devel
<Borromini>
lipnitsk: sounds even more way over my head ;)
<rsalvaterra>
Borromini: I was actually thinking of my TL-WDR3600… It's got a AR8327N switch, should be supported by qca8k, no?
<Borromini>
i have no idea about what qca8k supports, not familiar with it sorry.
<Borromini>
isn't it supposed to be the next driver for QCA switches in openwrt at some point?
<Borromini>
rsalvaterra: do you have any mwlwifi devices?
<lipnitsk>
infradead is pretty aptly named at the moment, because it is well... dead
<Borromini>
i thought so but might be confusing you with someone else.
<rsalvaterra>
Possibly… It was written by blogic, he probably knows better. :)
<Borromini>
:)
<Borromini>
mwlwifi doesn't do WPA3 does it?
Tapper has quit [Ping timeout: 245 seconds]
<rsalvaterra>
Borromini: Nope, mwlwifi doesn't do WPA3 or WPA2 with PMF. Only plain WPA2.
<Borromini>
someone on the forum is claiming his wrt1200ac does...
dedeckeh has joined #openwrt-devel
<Borromini>
makes you wonder (about his statement)
<rsalvaterra>
A friend of mine has both a WNDR3700 and a WRT1200AC. Guess which one is his favourite.
<rsalvaterra>
Borromini: blocktrron's branch backports the ar9331 switch driver to 5.4. It's available natively in Linux 5.10, so that might make things easier.
<Borromini>
rsalvaterra: neat
<Borromini>
you really want to play with 5.10 don't you ;)
linzst has quit [Quit: Leaving]
<rsalvaterra>
Borromini: I *am* playing with 5.10, both on the Omnia and on the TL-WDR3600. Archer C6 will be next. And I'm just waiting for lipnitsk's pull to land, to install it on the RM2100. ;)
<Borromini>
hehe
<rsalvaterra>
But now I'm trying to understand why tc is failing to build here… I'm compiling libelf with MIPS16, I wonder if that's a problem (libbpf can't be compiled with MIPS16 and depends on libelf)…
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
adrianschmutzler has joined #openwrt-devel
repulse has quit [Quit: repulse]
whitewolf has quit [Ping timeout: 256 seconds]
whitewolf has joined #openwrt-devel
<guidosarducci>
rsalvaterra: pong. hey, stop breaking things! :-) I turn MIPS16 explicitly turned off for bpftools -- not an accident, as the assembler errors in your logs will probably show.
<rsalvaterra>
guidosarducci: But I like breaking things… :P
<guidosarducci>
rsalvaterra: in other news, finished testing a nice clean, non-kludgy iproute2 update for a tc-tiny. Writing a description and then PR.
<rsalvaterra>
guidosarducci: Aww! I'm at it too! :P
<rsalvaterra>
Bring it on! :D
Tapper has joined #openwrt-devel
<guidosarducci>
rsalvaterra: then don't make it sound like iproute2/bpftools broke, when you broke it on purpose :-P
<guidosarducci>
rsalvaterra: yeah, give me a few minutes to write something clear. I'm not a committer; I can't get away with one line "update package XXX" committs to master...
<rsalvaterra>
guidosarducci: Well, I didn't break it on purpose… thing is, my tc-tiny doesn't link to libbpf (nor libelf), so I hadn't noticed the breakage until I tried building tc-full.
<guidosarducci>
rsalvaterra: didn't I tell you that's a tricky package to maintain? Tell me about it... :-)
<jow>
yay, nftables i/oifname matching bug tracked down to kernel strncpy() behaving differently on mips
<rsalvaterra>
jow: Oh, my…
<rsalvaterra>
Must have been a nice rabbit hole. :P
<rmilecki>
jow: what?
<guidosarducci>
jow: does a fw4 + nftables support all uci firewall config options?
<guidosarducci>
jow: I remember seeing a while ago it switches to using something ECMAscriptish too? What improvements does that bring?
<guidosarducci>
philipp64: ping
<philipp64>
guidosarducci: pong
figgyc has quit [Quit: figgyc]
<guidosarducci>
philipp64: howdy, was wondering if you had a chance to look at the libelf updates related to x86_64 on 5.10? Any thoughts?
<jow>
rmilecki: apparently the kernel shipped quite naive asm implementations of strcpy(), strncpy() and strcmp() which aren't really better than the generic C counterparts but which lack certain side effects
<philipp64>
I glanced at them, but was going to give it a more hermenutical reading later... Right now I'm eyeballs deep in trying to figure out what CircleCI is so broken, and why we keep seeing false positives. It's been weeks since it gave a valid x86_64 build result...
<jow>
rmilecki: the strncpy() function is supposed to pad the remainder of the dest buffer with zeroes even if the src string to copy is shorter than the given length
<jow>
rmilecki: the MIPS ASM variant does not
<rmilecki>
jow: i had to be painful
<philipp64>
jow: "more harm has been done by unnecessary micro-optimizations than all naivete combined..." (-me)
<Borromini>
blogic: happy birthday ^_^
<jow>
nftables relies on that behaviour, it copies IFNAMSIZ bytes into a scratch buffer and expects it to be zero-initialized
<rsalvaterra>
jow: You're basically saying nftables is broken on MIPS. Peachy!
<philipp64>
"he strncpy() function is supposed to pad the remainder of the dest buffer with zeroes even if the src string to copy is shorter than the given length" -- you sure about that? the glibc man page states otherwise:
<philipp64>
The strncpy() function is similar, except that at most n bytes of src
<philipp64>
are copied. Warning: If there is no null byte among the first n bytes
<philipp64>
of src, the string placed in dest will not be null-terminated.
<karlp>
glibc isn't exactly the one truth these days....
<jow>
sreg is the scratch buffer, data the compare buffer
<jow>
they're memcmp'ed
<philipp64>
karlp: they are pretty zealous about following the ANSI/ISO standards and calling out when they don't...
<philipp64>
if you're going to provide a function with a cannonical name like strncpy(), why give deviant semantics? that's just asking for trouble... I don't care if it is in the kernel...
<karlp>
philipp64: your definition absolutely won't do what the kernel version does...
<karlp>
kernel world doesn't give a rats abotu what user calls look like.
<philipp64>
or rather, the kernel won't do what I described (which is what the ISO C99 language spec requires).
<philipp64>
well, you get into deep kimchi for iptables/netfilter developers that write code for both sides of the kernel (kernel- and user-spaces)... only a matter of time that someone ends up forgetting about the subtle differences between the two versions. Asking for trouble.
<rsalvaterra>
philipp64: Let's put it this way: libc relies on the kernel, not the other way around. ;)
<philipp64>
rsalvaterra: I get that. But there's an infinite number of alternate names for the function that was unfortunately called "strncpy()" in the kernel...
<guidosarducci>
philipp64: understood re: libelf, just didn't want it to fall off the stack. Let me know if anything I can help with. And can't agree more about senseless overoptimization, but it's become common culture and good luck changing people. :-)
<jow>
guidosarducci: yes, fw4 will support allmost all uci options
<jow>
guidosarducci: about the ECMAscriptishness, main advantage is that it is easer than maintaining a C wrapper
<jow>
and idea is to eventually reuse ucode in other places as well where shell script is not well suited (lack of complex data structures, json/ubus integration)
<guidosarducci>
jow: sure, I was concerned with it looking like a one-off, and your own fork at that, so a maintainability issue. Not sure if I misunderstood.
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
hexa- is now known as H
H is now known as hexa-
silverwhitefish has joined #openwrt-devel
<Tapper>
blogic: happy birthday
<guidosarducci>
jow: first thought was what ruled lua out as a good fit TBH.
<guidosarducci>
rsalvaterra: sorry, missed your link earlier.
<jow>
guidosarducci: thought a whilr about Lua as option but in the end I found the code too verbose
<jow>
also the incompatibilities with each version were annoying as well, the lack of a good standard lib, functions such as map, filter
<jow>
lambdas
<jow>
clear array vs table separation
<jow>
json parse & formatting
<jow>
ubus integration
<jow>
yes, can be all supplemented with modules
<jow>
but then you need to forward port to lua 5.4
<guidosarducci>
jow: yeah, I can sympathize. Am I right that's it's your own JS fork/version? Is there something with upstream support we can use?
<jow>
its neither a fork nor JS, its a custom implementation that happens to reuse ecmascript syntax but without the class and prototype inheritation model
<jow>
upstream would be me
<guidosarducci>
jow: also, there's a flip side to verbose code. TBH I found the f3 code rather opaque and inaccessible, which is worrisome given how central it is to OWRT and security.
black_an- has quit [Ping timeout: 245 seconds]
<jow>
me too, therfore I didn't want to write it in C, again
<jow>
but then I don't want to write 15 lines of code every time I want to remove an item from an array
<jow>
or restructure loop conditions because there's no continue
<jow>
(Lua 5.1)
<guidosarducci>
jow: I also worry about the lack of regression testing (that I've seen) for fw code. Does this change help enable any such improvements?
<jow>
sure, since fw4 simply renders nftables syntax which is fed to nft via stdin you can simply feed it uci and compare the expected output
<guidosarducci>
jow: but how do we test the fw3 to fw4 transition?
gnustomp has quit [Ping timeout: 264 seconds]
<jow>
I am going to focus on testing that fw4 produces the expected nftables result from the given uci
<jow>
in the end we have to rely on nftables performing as intended
<guidosarducci>
jow: Right, I expect "all of us" is the real answer to "who/how". But if we can even build a test set going forward that'll still be very useful.
<guidosarducci>
jow: thanks for the insight, I appreciate it. Can I bug you about a fw bug? The DSCP/MARK targets completely ignore interface. Everything is run in PREROUTING, all interfaces and directions. It hurts people transitioning to use fw uci rather than custom iptables rules.
<guidosarducci>
jow: ^^^ I'm actually talking about the targets in fw3 uci.
<guidosarducci>
rsalvaterra: saw your log. I build iproute2/bpftools all the time and don't see that compile error, so first question is what did you change? :-P
<jow>
guidosarducci: right, the mangle table management in fw3 lacks the entire zone/chain matching infrastructure
<jow>
so it's not so much a bug but rather a lacking feature
<jow>
the bug would be not warning/rejecting MARK/DSCP rules with option src/dest
<rsalvaterra>
guidosarducci: Let me push it, I'll show you…
<guidosarducci>
jow: well, IIRC the usage description when it was implemented said it should work.
<jow>
did it? couldn't find a usage description in the commit messages from a quick glance
<guidosarducci>
jow: no it does indeed accept src, it just doesn't use it as originally intended. I'd like to fix 'src', and then add 'dst'.
<guidosarducci>
jow: it was either a forum discussion, or an older wiki page version I can't seeem to find just now.
<guidosarducci>
jow: it correctly rejects 'dst':
<guidosarducci>
Warning 'dest' for DSCP target
<guidosarducci>
: Section @rule[13] (Test-MARK-3) must not specify 'dest' for MARK target
<jow>
to fix src (and possible add dest) you'd first need to setup the entire chain structure in the mangle table
<jow>
and add the appropriate zone match rules (e.g. -i br-lan -j zone_lan_mangle)
<jow>
but for mark/dscp that's likely not feasible
<jow>
so you likely want to keep it flat (stuff all in PREROUTING) and loop over all permutations of (&rule->_src->networks and &rule->_dest->networks)
<guidosarducci>
jow: would that consolidate the filter and mangle stuff in the same framework? Might be good in any case.
<jow>
so if you have a config rule; option src lan; option dest wan; option target MARK; option set_mark 1234 with zone "lan" and "wan" having multiple interfaces or subnets each (e.g. eth0+eth1 in wan, eth2+eth3 in lan)
<jow>
there you have a src matching chain (e.g. -i eth2 and -i eth3 both jumping to zone_lan_input
<jow>
and the dest part is realized by jumping into the appropriate target chain
<jow>
you could do the same for mangle, e.g. have a zone_lan_input which is then jumping into a zone_wan_dscp or zone_wan_mark
<guidosarducci>
jow: right, that's what I was imagining for mangle too.
<guidosarducci>
but it sounds like that requires a lot of infrastructure to do.
<jow>
yes
<jow>
also I'm a bit fuzzy atm
<jow>
in which contexts does set-dscp or set-mark make sense?
<jow>
for output and forward?
<jow>
I guess not for input
<guidosarducci>
jow: really mainly for prerouting and postrouting, maybe forwarding.
<guidosarducci>
jow: where forwarding case == in && out
<jow>
how to configure pre or post in uci?
<guidosarducci>
jow: the big use case is specifying QOS classifiers in a maintainable, portable way, rather than have people subtly breaking our firewall rules.
<jow>
atm there's only src yes/no and dest yes/no
<jow>
src only is input, dest only is output, both is forward
<guidosarducci>
jow: pre would naturally translate from a 'src', which a zone spec?
<jow>
for nat, pre/postrouting is selected according to the target (dnat vs. snat/masq)
<jow>
but they're mainly considered to apply to forwarded traffic
<jow>
ok so target MARK/DSCP + only src -> mangle/prerouting
<jow>
target MARK/DSPC + src + dest -> mangle/forwarding
<guidosarducci>
jow: exactly
<jow>
MARK/DSCP + only dest -> mangle/postrouting ?
<guidosarducci>
yes
<jow>
gotcha
<guidosarducci>
jow: I'm sure others will want to see INPUT and OUTPUT w.r.t. to on-device services but that can be a TBD. And I expect we'll have more flexibility in post-iptables, either nftables or bpfilter.
<guidosarducci>
jow: so really I'm just wondering how feasible that would be for 21.02, given it dates from 19.xx.
Borromini has quit [Quit: leaving]
<guidosarducci>
rsalvaterra: give me a sec, multitasking. FYI, I also just rebuilt everything without issue so...
<rsalvaterra>
guidosarducci: No worries, I'm just curious to understand where I screwed up. :)
<guidosarducci>
rsalvaterra: that error shouldn't happen from what I see, but you should double-check further back in your log when iproute2 does its feature detection i.e. libelf libbpf etc.
<rsalvaterra>
By the way, one thing that gets screwed up is the indentation, when packages conflict with each other and belong to a submenu. The most egregious example is the WirelessAPD submenu.
<philipp64>
does anyone know why "dovecot" is required to build as part of the Strongswan CircleCI dependencies?
silverwhitefish has quit [Quit: One for all, all for One (2 Corinthians 5)]
<guidosarducci>
rsalvaterra: didn't think so but just a guess. I also note you're not using libmnl based on feature detection, but I confirmed everything still works in that case.
<jow>
fw3_foreach loops at least once if the given list head is empty, so if either of option src/dest is unspecified, the loop will run once with idev/odev NULL
<jow>
you still need to check ->_src and ->_dest for non-NULL though and possibly pass an empty list head instead
<jow>
or do it in a separate code branch
<jow>
I guess supporting "option src *" / "option dest *" makes sense too, to not require specifying a specific zone but still be able to select between PREROUTING/POSTROUTING/FORWARD
rmilecki has quit [Ping timeout: 240 seconds]
<guidosarducci>
jow: true, though I imagine these non-selective cases to be less common. If you have a code branch for this, then I have some test cases already I can run through. However, I don't have regression tests for other functionality. Are those safe?
gnustomp has joined #openwrt-devel
<guidosarducci>
jow: ^^ I mean non-DSCP/MARK mangle functions, the "regular" stuff...
<jow>
there's not much to share with the filter cases since those are completely differently structured, chain-wise
<jow>
the fw3_ipt_rule_... stuff could be refactored into a helper function of course
<guidosarducci>
jow: that's what I expect, but doesn't stop me worrying about breakage
<jow>
since line 23-36 and 49+ are mostly identical
<jow>
the diff I pasted should nto affect any other rules
<guidosarducci>
jow: ok, thanks, that gives me something to play with. How best to follow up? The fw3 code is on a separate repo.
<jow>
try it against your use cases, see if it yields the proper result
<jow>
and maybe polish it a bit, consolidate redundant code etc.
<jow>
then you could git-send-email it with --subject-prefix="PATCH firewall3"
<jow>
or get back to me here
<jow>
need to run now, bbl
<guidosarducci>
jow: thanks a lot, take care
Tost has quit [Ping timeout: 240 seconds]
<pkgadd>
rsalvaterra: you're successfully running kernel 5.10 on your tl-wdr3600? anything special to consider? (I was planning to look into v5.10 for my tl-wdr3600 and tl-wdr4300 over the coming days)
<rsalvaterra>
pkgadd: Yes, I am, and it seems to be just fine (haven't tested my cdc-ncm connection yet, though). Built with gcc 10 and binutils 2.35.1, -mtune=74kc -O2.
<pkgadd>
great, thanks! (just need to look again where I to the patches)