**** BEGIN LOGGING AT Tue Mar 02 02:59:58 2021 Mar 02 03:23:42 is it possible to successfully spawn pppd from a console? o_e Mar 02 03:24:13 I've tried exec + removing askconsole from the inittab but no dice Mar 02 04:15:32 build #271 of ar71xx/generic is complete: Failure [failed targetupload] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fgeneric/builds/271 blamelist: Adrian Schmutzler Mar 02 04:15:46 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 , ?lvaro Fern?ndez Rojas , Sebastian Kemper , Daniel Golle Mar 02 04:15:47 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 , Georgi Valkov , Ronny Kotzschmar , Stefan Lippers-Hollmann , Pawel Dembicki Mar 02 04:15:47 Mar 02 04:29:46 For the package folks.. Usig PKG_INSTALL = 1 should call make install after the first make, correct? Mar 02 05:08:26 Grommish: when did you start having a packet loss on your itus shield? after 5.10 or after cn63xx errata patch merge? Mar 02 05:08:46 because on 5.4 it was tested to be working fine. Mar 02 05:08:57 damex: I never had a working 5.10 version Mar 02 05:09:15 I get the same ehci kernel panic Borromini gets on the ERLite Mar 02 05:09:34 I've not had time to test anything further because dnsmasq is being stupid Mar 02 05:12:34 damex: I'm working on a SysBench package to run benchies between versions though Mar 02 05:13:47 damex: https://github.com/akopytov/sysbench I'll see hard numbers this way Mar 02 08:37:27 build #885 of pistachio/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/885 Mar 02 08:41:56 guidosarducci: ping Mar 02 08:50:26 build #826 of tegra/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/826 Mar 02 09:05:05 build #581 of bcm63xx/smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/581 Mar 02 09:28:24 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 Mar 02 09:30:35 nbd_: IIRC I've reported it 2 weeks ago when it was spotted for the first time https://gitlab.com/openwrt/project/ubus/-/pipelines Mar 02 09:32:03 build #627 of bcm27xx/bcm2711 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/627 Mar 02 09:32:54 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 Mar 02 09:42:57 build #808 of lantiq/xway_legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway_legacy/builds/808 Mar 02 09:51:36 ynezz: I'd suggest -DABIVERSION="$(if $(PKG_ABI_VERSION),$(PKG_ABI_VERSION),0)" Mar 02 09:52:20 or, slightly cleaner: PKG_ABI_VERSION ?= 0 somewhere at the top of the Makefile Mar 02 09:53:53 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? Mar 02 09:56:46 Yay! First LuCI pull request. :P https://github.com/openwrt/luci/pull/4863 Mar 02 09:58:06 the 'completely untested' sounds extremely tempting ;) Mar 02 09:59:14 Borromini: Heh… they're not exactly earth-shattering changes… :P Mar 02 10:01:49 rsalvaterra: the last time you said that it invoved gutting ssl ;p Mar 02 10:03:06 xD Mar 02 10:03:24 my motivation to merge untested commits is zero, as I personally lack the time Mar 02 10:03:44 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 Mar 02 10:04:07 Grommish: But the OpenSSL axe murder is fully tested (and running) on my machines. ;) Mar 02 10:04:22 rsalvaterra: Oh, well, nevermind then Mar 02 10:05:06 jow: so the only difference between native (host) and target (SDK) is CMake's toolchain file Mar 02 10:05:26 ynezz: ah ok, I understand Mar 02 10:05:55 jow: this out of tree builds usually expose different kind of CMake issues as well, hardcoded/implicit stuff etc. Mar 02 10:06:21 jow: I fully accept and understand. The idea was just to get it out there, someone interested will probably test it. ;) Mar 02 10:07:13 rsalvaterra: I'll leave it up and mess with it tomorrow if you'd like Mar 02 10:07:56 Grommish: If you use LuCI and zram-swap, that would be great, thanks! :) Mar 02 10:08:26 LuCI, yes, zRAM no.. no swap on the device Mar 02 10:08:38 I was going to ask about that ;p Mar 02 10:09:40 Grommish: zram is a RAM-based compressed block device. The typical use case for it is to create a compressed swap partition in RAM. Mar 02 10:09:56 (To be honest, I never saw it being use in a different way.) Mar 02 10:10:00 *used Mar 02 10:10:06 build #822 of ath79/nand is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/822 Mar 02 10:12:25 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. ;) Mar 02 10:13:29 Oh? Hmm.. I'll have to check it out after I do this other thing Mar 02 10:14:36 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 Mar 02 10:19:02 build #612 of bcm27xx/bcm2710 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/612 Mar 02 10:19:24 Grommish: This is how zram swap looks on my machine… https://paste.debian.net/1187484/ Mar 02 10:21:03 Grommish: The UCI configuration is different from upstream, at least for now, as I have this in my tree: https://github.com/rsalvaterra/openwrt/commit/ef37b16eacc5969665316e3d1d4e84a097b4e209 Mar 02 10:22:34 ynezz: another idea, maybe simply export PKG_ABI_VERSION=$(date +%Y%m%d) in your container? Mar 02 11:05:34 jow: yes, probably something like that if it's expexted and WONTFIX :) Mar 02 11:05:45 s/expexted/expected/ Mar 02 11:06:21 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. Mar 02 11:06:41 power cycle, and it's all good again Mar 02 11:17:02 build #667 of layerscape/armv7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/667 Mar 02 11:17:50 rsalvaterra: zram makes a disk-based swap partition to use as RAM, like regular swap? Mar 02 11:18:12 oh wait, maybe i'm just losing the serial console (somehow) ... tries flashing again Mar 02 11:18:44 Grommish: zram resides entirely in RAM, no physical storage involved. :) Mar 02 11:19:07 rsalvaterra: Then what's the point? Mar 02 11:19:31 rsalvaterra: I'm not understanding why partition RAM in RAM.. for the compression? Mar 02 11:20:09 that's what the z is... Mar 02 11:20:41 karlp: Right, but I'm still not sure what hte practical benefit is Mar 02 11:22:34 karlp: I'm not using it, and the question is, should I be :) Mar 02 11:22:39 rsalvaterra: https://gist.github.com/Grommish/48ed5c8467f5cdee3e878339c43454a7 Mar 02 11:22:53 from my understanding, opionins ar emixed :) the fans love it.... Mar 02 11:22:55 Grommish: Simple: a lot of code and data is used only once. If you can't swap it out, it will reside in RAM forever. Mar 02 11:22:56 try it and see? Mar 02 11:22:59 a little of both Mar 02 11:23:34 Grommish: By having a compressed swap in RAM, you can free those allocated pages by swapping them out. Mar 02 11:23:46 karlp: I"m still trying to quantify the octeon mess to see if a hit is taken :( Mar 02 11:24:21 if you cant' quantify, then... did it happen? :) Mar 02 11:24:28 karlp: but I'll check it out and see Mar 02 11:25:47 karlp: https://github.com/openwrt/openwrt/pull/3936#event-4386528991 Mar 02 11:26:45 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 Mar 02 11:27:02 at the expense of a single device that isn't maintained Mar 02 11:27:14 so.. I want to find out if and how much it effects things Mar 02 11:28:11 Oooooh…! Mar 02 11:29:01 * rsalvaterra totally forgot he can now set vm.swappiness to 200, on Linux 5.10. Mar 02 11:29:38 rsalvaterra: You'd be proud, i had to rebuild the MS WSL kernel for modules :) Mar 02 11:30:19 I build the kernel every week… :P Mar 02 11:30:25 and it still worked.. MS did a really decent job with WSL Mar 02 11:30:26 Right now: Linux presler 5.12.0-rc1+ #78 SMP Mon Mar 1 11:59:23 WET 2021 x86_64 GNU/Linux Mar 02 11:30:45 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 Mar 02 11:31:22 Nice…! 5.10.17 on WSL? (I never used WSL.) Mar 02 11:31:36 Yeah WSLv2 Mar 02 11:32:58 the WSLv2 kernel doesn't come with modules enabled and headers Mar 02 11:33:29 but, after that, it's been smooth.. once I limited the RAM it was eating Mar 02 11:33:50 Not having modules sounds like a feature to me… ;) Mar 02 11:35:16 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. Mar 02 11:36:49 * rsalvaterra thoroughly despises compat for that very reason… Mar 02 11:40:44 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 98.2% packages reproducible in our current test framework.) Mar 02 15:53:42 sigh nftables Mar 02 15:53:53 iifname/oifname matches not working but iif/oif does Mar 02 16:03:57 Assertion failed: (((len) + (8) - 1) / (8)) > 0 (expression.c: constant_expr_alloc: 394) Mar 02 16:04:00 Aborted Mar 02 16:04:01 ... sigh Mar 02 16:06:00 apparently the ifname string matching is not actually matching ifnames Mar 02 16:06:11 staged four different counter rules to test: Mar 02 16:06:23 https://pastebin.com/45pXH07q Mar 02 16:29:46 jow: Hacking on firewall4? :) Mar 02 16:30:31 its done more or less. But whenever I stop looking for a week, the groundwork is crumbling Mar 02 16:31:20 Wait, you mean nftables is still a moving target? Mar 02 16:31:36 apparently? Mar 02 16:31:47 whenever I look at it too long it falls over Mar 02 16:31:55 but its probably my fault Mar 02 16:33:27 I wouldn't know, to be honest… I never used nftables, so I will have to learn from scratch. Mar 02 16:33:43 it looks promising Mar 02 16:33:56 for example I was able to consolidate ipv4 and ipv6 into one ruleset Mar 02 16:34:09 within the af agnostic "inet" table Mar 02 16:34:28 anonymous sets etc. are nice as well Mar 02 16:34:37 syntax is okayish Mar 02 16:34:56 but it is quite a paradigm shift Mar 02 16:35:30 https://github.com/openwrt/openwrt/pull/3960 boom, I hope it gets merged Mar 02 16:37:31 jow: That's why I'll wait for firewall4, firewall3 helped me understand a lot of details about iptables. :) Mar 02 16:39:24 jow will firewall 3 just be swaped out with firewall 4. Mar 02 16:39:48 Oh, and this too, of course… https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg Mar 02 16:39:49 swopped* Mar 02 16:40:21 Tapper: yes, for the majority of use cases you cna just replace the package Mar 02 16:40:26 config etc. remains identical Mar 02 16:40:31 Will there have to be changes to other packages like addblock and banip egeg Mar 02 16:40:35 no Mar 02 16:40:45 or rather, depends Mar 02 16:40:53 if they do firewall ops via ubus, then no Mar 02 16:40:54 Sounds good Mar 02 16:41:00 if they do manual iptables, then yes Mar 02 16:41:08 kk Mar 02 16:41:14 however iptables and nftables can coexists to some extent Mar 02 16:41:28 but it'd be a waste of space and hard to debug if things do not work Mar 02 16:41:35 What be the advantages of firewall 4 then? Mar 02 16:41:48 future proof Mar 02 16:42:02 iptables is being phased out and nowaday it is just a compatibility wrapper around iptables Mar 02 16:42:07 * Tapper nods Mar 02 16:42:12 *around nftables I mean Mar 02 16:42:24 kk thanks for your work on this then Mar 02 16:42:31 jow: Future proof… until bpftables takes off, of course… ;) Mar 02 16:42:37 yeah Mar 02 16:42:57 well they opted for the virtual machine route, so in the end it's all just different language frontends Mar 02 16:43:14 which will be compiled to some low level matching vm Mar 02 16:44:52 Somehow, that will require an eBPF compiler in the router itself… I can imagine the storage requirements skyrocketing in the near future. Mar 02 16:50:43 any opinion on squashing cherry-picks together in a 21.02 PR? Mar 02 16:50:50 yay, nay, doesn't matter? Mar 02 16:52:03 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 Mar 02 16:52:30 a different compiler frontend or a cross-compile toolchain will be needed Mar 02 16:52:48 the latter will make it impossible to change rules/filter programs on-target though Mar 02 16:53:35 jow: That's going to be wonderful on 8 MiB devices. :) Mar 02 16:53:37 so either you write a generic ebpf program which you can somehow pass parameters to, like building a crappy variant of nftables Mar 02 16:54:10 or you build another compiler frontend which emits the necessary risc byte code and which does the ELF framing manually Mar 02 16:54:14 jow: Or you generate your rules on the local machine and upload the ready-to-eat BPF bytecode to the router… Mar 02 16:54:36 yeah or that, but compared to plain text rules that is quite impractical Mar 02 16:55:03 requires a linux machine / docker container / sdk / webservice to compile opague binary blobs which you then load into the kernel Mar 02 16:55:16 does not really inspire confidence Mar 02 16:55:42 Right, too convoluted for my taste. Mar 02 16:56:09 Inquiry from the curious: is that said binary compiled FW ruleset then also more performant than plain text? :) Mar 02 16:56:27 sometime this year I want to take a stab at building an alternative compiler for ebpf Mar 02 16:57:04 olmari: Insanely fast, according to some prototype benchmarks I've seen years ago. Mar 02 16:58:59 https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables Mar 02 16:59:36 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 :) Mar 02 17:01:26 And comparing the performance of iptables and nftables, I can't see a compelling reason to switch to nftables. Mar 02 17:47:14 So what, rebuild the linux kernel network filtering stack to be more like how graphics work? Mar 02 17:47:51 everything precompiled jit? those'll be some fat libraries :| Mar 02 17:51:21 hurricos: essentially, yes (bytecode/jit) Mar 02 17:53:27 christ, I'd love to imagine a world where OpenWrt could self-compile those at runtime and host different arch toolchains Mar 02 17:53:53 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 Mar 02 17:54:04 but on the other hand, spend more than 4 seconds thinking about it and that looks so Mar 02 17:54:06 so so so bad Mar 02 17:55:14 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 Mar 02 17:55:18 or wait no. Mar 02 17:57:01 Well Mar 02 17:57:14 OK, the one thought there is that, maybe for bigger managed switches. Mar 02 17:57:36 Like, imagine if a vendor marks redistributable some switch ASIC binaries and now suddenly the P2020 whitebox switches are on the market Mar 02 17:58:22 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 Mar 02 17:58:51 but still, can't see the synergy with OpenWrt's main targets Mar 02 18:05:02 also ONIE already has that market cornered Mar 02 19:10:00 ... Mar 02 19:10:12 so today 2.3. i turned 42 ;P Mar 02 19:10:23 been waiting for my 2342 day for decades Mar 02 19:10:41 what are the odds on that one .... Mar 02 19:10:43 happy birthday:-) Mar 02 19:12:59 blogic: Heh… I'll be 40 this year… :P Happy birthday! ;) Mar 02 19:14:20 spent the day with my daughter building the big lego harry p[otter castle ;) Mar 02 19:15:46 I miss the Lego (Technic) from my childhood… It's all very commercial, nowadays. Mar 02 19:15:56 yeah Mar 02 19:16:00 still was fun Mar 02 19:53:24 is openwrt-devel ML alive? Mar 02 19:53:48 https://lists.infradead.org/mailman/listinfo/openwrt-devel seems dead? Mar 02 19:54:00 and my email either got rejected or the list is just dead? Mar 02 19:56:01 lipnitsk: https://downforeveryoneorjustme.com/lists.infradead.org Mar 02 19:56:09 it's not just you ; Mar 02 19:56:10 ;) Mar 02 19:56:20 thanks for the detective work on the ramips 5.10 PR btw Mar 02 19:56:25 haha, is that controlling the ML operations? Mar 02 19:56:41 no it's a site that offers you a sanity check :) Mar 02 19:56:48 yeah, good thing there are willing testers. Mar 02 19:56:54 No, I mean the infradead site Mar 02 19:57:02 infradead.org hosts the ML yes Mar 02 19:57:12 okay, so just resend when it's back up? Mar 02 19:57:14 it hosts multiple i think. Mar 02 19:57:18 or will it process the queue? Mar 02 19:57:19 yeah, probably Mar 02 19:57:24 i guess just wait and see Mar 02 19:57:25 i have no idea, sorry. Mar 02 19:57:53 you can ping dwmw2_gone i think he runs it/has access to it Mar 02 19:58:27 lipnitsk: is that XTAL_MASK 3 bits in 5.4 still btw? i looked for it but couldn't find it Mar 02 19:58:38 nah, its not even in 5.10 Mar 02 19:58:46 oh i mean sorry Mar 02 19:58:58 I think it was just an issue on mainline Mar 02 19:59:28 I tried backporting the mainline to 5.10 and it backfired, but we found the bug as a result Mar 02 19:59:42 my PR just uses the staging version of the driver from 5.10 now with a small Kconfig change. Mar 02 19:59:46 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 Mar 02 19:59:50 ok Mar 02 20:00:03 the reset issue is something else, I was confused Mar 02 20:00:20 resets may be misconfigured and that's fixed via device tree, but this was a driver bug. Mar 02 20:00:37 ok. i thought it was related going by what was said in the comments, but I know nothing about the code really. Mar 02 20:01:16 I know nothing about that code either, and Sergio was very helpful in patiently explaning it ;) Mar 02 20:01:27 I guess he got a bug fix and some testing out of it so he should be happy ;) Mar 02 20:02:17 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) Mar 02 20:02:19 now if we can bisect the packet loss that would be great. I think the branch is pretty much ready to merge even now.. Mar 02 20:02:25 :) Mar 02 20:02:50 Guys, is it possible to test DSA on ath79 devices already? :) Mar 02 20:03:36 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 Mar 02 20:03:48 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 Mar 02 20:04:39 lipnitsk: sounds even more way over my head ;) Mar 02 20:06:06 Borromini: I was actually thinking of my TL-WDR3600… It's got a AR8327N switch, should be supported by qca8k, no? Mar 02 20:06:42 i have no idea about what qca8k supports, not familiar with it sorry. Mar 02 20:07:20 isn't it supposed to be the next driver for QCA switches in openwrt at some point? Mar 02 20:08:42 rsalvaterra: do you have any mwlwifi devices? Mar 02 20:08:52 infradead is pretty aptly named at the moment, because it is well... dead Mar 02 20:08:57 i thought so but might be confusing you with someone else. Mar 02 20:09:00 Possibly… It was written by blogic, he probably knows better. :) Mar 02 20:09:08 :) Mar 02 20:09:26 mwlwifi doesn't do WPA3 does it? Mar 02 20:10:01 Borromini: Nope, mwlwifi doesn't do WPA3 or WPA2 with PMF. Only plain WPA2. Mar 02 20:10:14 someone on the forum is claiming his wrt1200ac does... Mar 02 20:10:24 makes you wonder (about his statement) Mar 02 20:11:07 Borromini: Probably someone special. :P Mar 02 20:11:12 :P Mar 02 20:12:45 A friend of mine has both a WNDR3700 and a WRT1200AC. Guess which one is his favourite. Mar 02 20:17:11 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. Mar 02 20:17:38 rsalvaterra: neat Mar 02 20:17:50 you really want to play with 5.10 don't you ;) Mar 02 20:21:56 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. ;) Mar 02 20:23:02 hehe Mar 02 20:26:22 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)… Mar 02 20:37:46 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 98.4% packages reproducible in our current test framework.) Mar 02 20:38:01 Now CI/CD is failing because of dovecot? https://paste.centos.org/view/a50b814d Mar 02 21:05:49 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. Mar 02 21:07:58 guidosarducci: But I like breaking things… :P Mar 02 21:08:17 rsalvaterra: in other news, finished testing a nice clean, non-kludgy iproute2 update for a tc-tiny. Writing a description and then PR. Mar 02 21:08:53 guidosarducci: Aww! I'm at it too! :P Mar 02 21:09:09 Bring it on! :D Mar 02 21:09:30 rsalvaterra: then don't make it sound like iproute2/bpftools broke, when you broke it on purpose :-P Mar 02 21:11:00 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... Mar 02 21:11:40 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. Mar 02 21:12:46 rsalvaterra: didn't I tell you that's a tricky package to maintain? Tell me about it... :-) Mar 02 21:13:58 blogic: happy birthday Mar 02 21:14:23 russell--: were your able to confirm your oxnas build issue went away with https://github.com/openwrt/openwrt/pull/3956 ? Mar 02 21:14:51 But like I said, it's probably the old libelf MIPS16 commit I had causing issues. I reverted it, let's see how it goes. Mar 02 21:17:09 ynezz: thanks for the d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") Mar 02 21:17:54 rsalvaterra: strange, in PR https://github.com/openwrt/openwrt/pull/3926 I made sure to test by compiling against iproute2. What are your logs showing? Mar 02 21:18:04 ynezz: i hope we can get upstream MAC reading support soon Mar 02 21:18:06 blogic: many happy returns! Mar 02 21:19:13 guidosarducci: Still building. Pentium (4) D here, it'll take a while. If it fails, I'll let you know. :P Mar 02 21:19:37 build #689 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/689 Mar 02 21:20:16 yay, nftables i/oifname matching bug tracked down to kernel strncpy() behaving differently on mips Mar 02 21:20:52 jow: Oh, my… Mar 02 21:21:08 Must have been a nice rabbit hole. :P Mar 02 21:22:40 jow: what? Mar 02 21:22:42 jow: does a fw4 + nftables support all uci firewall config options? Mar 02 21:26:03 jow: I remember seeing a while ago it switches to using something ECMAscriptish too? What improvements does that bring? Mar 02 21:26:44 philipp64: ping Mar 02 21:27:44 guidosarducci: pong Mar 02 21:29:34 philipp64: howdy, was wondering if you had a chance to look at the libelf updates related to x86_64 on 5.10? Any thoughts? Mar 02 21:30:53 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 Mar 02 21:31:08 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... Mar 02 21:31:30 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 Mar 02 21:31:38 rmilecki: the MIPS ASM variant does not Mar 02 21:31:55 jow: i had to be painful Mar 02 21:31:57 jow: "more harm has been done by unnecessary micro-optimizations than all naivete combined..." (-me) Mar 02 21:32:04 blogic: happy birthday ^_^ Mar 02 21:32:21 nftables relies on that behaviour, it copies IFNAMSIZ bytes into a scratch buffer and expects it to be zero-initialized Mar 02 21:32:53 jow: You're basically saying nftables is broken on MIPS. Peachy! Mar 02 21:33:04 "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: Mar 02 21:33:06 The strncpy() function is similar, except that at most n bytes of src Mar 02 21:33:07 are copied. Warning: If there is no null byte among the first n bytes Mar 02 21:33:08 of src, the string placed in dest will not be null-terminated. Mar 02 21:33:30 glibc isn't exactly the one truth these days.... Mar 02 21:33:38 jow: congrats on finding that Mar 02 21:33:54 philipp64: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/string.c#n109 Mar 02 21:34:22 kernel vs libc definitions yaya Mar 02 21:34:24 the safest way to use strncpy() is: dst[sizeof(dst)-1] = '\0'; strncpy(dst, sizeof(dst) - 1, str); Mar 02 21:34:29 in practise it looks like this on an mt7621 device right now: https://pastebin.com/iR6gXbuT Mar 02 21:34:41 sreg is the scratch buffer, data the compare buffer Mar 02 21:34:45 they're memcmp'ed Mar 02 21:34:59 karlp: they are pretty zealous about following the ANSI/ISO standards and calling out when they don't... Mar 02 21:36:31 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... Mar 02 21:36:40 philipp64: your definition absolutely won't do what the kernel version does... Mar 02 21:36:50 kernel world doesn't give a rats abotu what user calls look like. Mar 02 21:37:11 or rather, the kernel won't do what I described (which is what the ISO C99 language spec requires). Mar 02 21:38:24 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. Mar 02 21:38:24 philipp64: Let's put it this way: libc relies on the kernel, not the other way around. ;) Mar 02 21:39:11 rsalvaterra: I get that. But there's an infinite number of alternate names for the function that was unfortunately called "strncpy()" in the kernel... Mar 02 21:39:23 #netfilter suggested applying https://patchwork.kernel.org/project/linux-mips/patch/20191008194552.2176475-1-paul.burton@mips.com/ Mar 02 21:39:33 can confirm that it fixes the issue for me Mar 02 21:40:57 Bash was updated last on Dec 30, 2020. Why am I *now* seeing breakage when building it? Mar 02 21:41:31 The following seems to fix it, however: https://paste.ubuntu.com/p/kBDZxQtGqx/ Mar 02 21:43:34 jow: You're testing on Linux 5.4, right? From the patch date, it's probably already on Linux 5.10 (haven't checked). Mar 02 21:43:47 yes, 5.4 Mar 02 21:44:58 Yep, it's in 5.10. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/mips/include/asm/string.h?h=linux-5.10.y Mar 02 21:47:03 guidosarducci: https://paste.debian.net/1187564/ Mar 02 21:51:32 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. :-) Mar 02 21:52:25 guidosarducci: yes, fw4 will support allmost all uci options Mar 02 21:53:01 guidosarducci: about the ECMAscriptishness, main advantage is that it is easer than maintaining a C wrapper Mar 02 21:54:14 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) Mar 02 21:54:16 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. Mar 02 21:58:24 blogic: happy birthday Mar 02 21:59:12 jow: first thought was what ruled lua out as a good fit TBH. Mar 02 22:00:15 rsalvaterra: sorry, missed your link earlier. Mar 02 22:00:42 guidosarducci: thought a whilr about Lua as option but in the end I found the code too verbose Mar 02 22:01:35 also the incompatibilities with each version were annoying as well, the lack of a good standard lib, functions such as map, filter Mar 02 22:01:38 lambdas Mar 02 22:01:47 clear array vs table separation Mar 02 22:01:56 json parse & formatting Mar 02 22:02:01 ubus integration Mar 02 22:02:14 yes, can be all supplemented with modules Mar 02 22:02:31 but then you need to forward port to lua 5.4 Mar 02 22:03:57 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? Mar 02 22:04:43 its neither a fork nor JS, its a custom implementation that happens to reuse ecmascript syntax but without the class and prototype inheritation model Mar 02 22:04:55 upstream would be me Mar 02 22:05:23 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. Mar 02 22:05:45 me too, therfore I didn't want to write it in C, again Mar 02 22:06:25 but then I don't want to write 15 lines of code every time I want to remove an item from an array Mar 02 22:06:56 or restructure loop conditions because there's no continue Mar 02 22:07:10 (Lua 5.1) Mar 02 22:08:30 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? Mar 02 22:09:15 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 Mar 02 22:11:13 jow: but how do we test the fw3 to fw4 transition? Mar 02 22:13:05 I am going to focus on testing that fw4 produces the expected nftables result from the given uci Mar 02 22:13:32 in the end we have to rely on nftables performing as intended Mar 02 22:13:53 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. Mar 02 22:16:06 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. Mar 02 22:17:12 jow: ^^^ I'm actually talking about the targets in fw3 uci. Mar 02 22:21:20 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 Mar 02 22:22:10 guidosarducci: right, the mangle table management in fw3 lacks the entire zone/chain matching infrastructure Mar 02 22:22:26 so it's not so much a bug but rather a lacking feature Mar 02 22:22:42 the bug would be not warning/rejecting MARK/DSCP rules with option src/dest Mar 02 22:23:04 guidosarducci: Let me push it, I'll show you… Mar 02 22:23:24 jow: well, IIRC the usage description when it was implemented said it should work. Mar 02 22:25:27 did it? couldn't find a usage description in the commit messages from a quick glance Mar 02 22:25:46 guidosarducci: https://github.com/rsalvaterra/openwrt/commit/d6bfcd4b439d2308109b5a4deacb3ef2b8a9e313 Mar 02 22:26:37 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'. Mar 02 22:27:22 jow: it was either a forum discussion, or an older wiki page version I can't seeem to find just now. Mar 02 22:28:35 jow: it correctly rejects 'dst': Mar 02 22:29:15 Warning 'dest' for DSCP target Mar 02 22:29:15 : Section @rule[13] (Test-MARK-3) must not specify 'dest' for MARK target Mar 02 22:30:06 to fix src (and possible add dest) you'd first need to setup the entire chain structure in the mangle table Mar 02 22:30:41 and add the appropriate zone match rules (e.g. -i br-lan -j zone_lan_mangle) Mar 02 22:31:19 but for mark/dscp that's likely not feasible Mar 02 22:32:26 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) Mar 02 22:33:32 jow: would that consolidate the filter and mangle stuff in the same framework? Might be good in any case. Mar 02 22:33:43 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) Mar 02 22:34:22 you'd need 4 iptables rules with -i eth0 -o eth2; -i eth0 -o eth3; -i eth1 -o eth2; -i eth1 -o eth3 Mar 02 22:34:42 no for filter we act differently Mar 02 22:36:00 there you have a src matching chain (e.g. -i eth2 and -i eth3 both jumping to zone_lan_input Mar 02 22:36:31 and the dest part is realized by jumping into the appropriate target chain Mar 02 22:36:54 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 Mar 02 22:37:05 jow: right, that's what I was imagining for mangle too. Mar 02 22:37:48 but it sounds like that requires a lot of infrastructure to do. Mar 02 22:37:51 yes Mar 02 22:37:56 also I'm a bit fuzzy atm Mar 02 22:38:08 in which contexts does set-dscp or set-mark make sense? Mar 02 22:38:22 for output and forward? Mar 02 22:38:27 I guess not for input Mar 02 22:38:51 jow: really mainly for prerouting and postrouting, maybe forwarding. Mar 02 22:39:19 jow: where forwarding case == in && out Mar 02 22:40:04 how to configure pre or post in uci? Mar 02 22:40:08 jow: the big use case is specifying QOS classifiers in a maintainable, portable way, rather than have people subtly breaking our firewall rules. Mar 02 22:40:36 atm there's only src yes/no and dest yes/no Mar 02 22:41:01 src only is input, dest only is output, both is forward Mar 02 22:41:04 jow: pre would naturally translate from a 'src', which a zone spec? Mar 02 22:41:18 for nat, pre/postrouting is selected according to the target (dnat vs. snat/masq) Mar 02 22:41:42 but they're mainly considered to apply to forwarded traffic Mar 02 22:42:26 ok so target MARK/DSCP + only src -> mangle/prerouting Mar 02 22:42:43 target MARK/DSPC + src + dest -> mangle/forwarding Mar 02 22:42:45 jow: exactly Mar 02 22:43:01 MARK/DSCP + only dest -> mangle/postrouting ? Mar 02 22:43:06 yes Mar 02 22:43:22 gotcha Mar 02 22:44:31 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. Mar 02 22:45:53 jow: so really I'm just wondering how feasible that would be for 21.02, given it dates from 19.xx. Mar 02 22:51:10 rsalvaterra: give me a sec, multitasking. FYI, I also just rebuilt everything without issue so... Mar 02 22:52:56 guidosarducci: No worries, I'm just curious to understand where I screwed up. :) Mar 02 22:54:33 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. Mar 02 22:54:51 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. Mar 02 22:54:55 does anyone know why "dovecot" is required to build as part of the Strongswan CircleCI dependencies? Mar 02 22:55:41 rsalvaterra: also are you applying this? PR https://github.com/openwrt/openwrt/pull/3956 Mar 02 22:56:21 Nothing but nothing has Depends: .*dovecot in tmp/.packageinfo so I'm wondering just how broken is CircleCI? Mar 02 22:56:44 guidosarducci: Feature detection: https://paste.debian.net/1187574/ Mar 02 22:57:20 guidosarducci: Oh…! No, I hadn't seen that pull. I wonder if it makes a difference… Mar 02 22:58:25 guidosarducci: I'd say not feasible Mar 02 22:58:36 took a quick look and its going to be quite complicated Mar 02 22:59:10 simplest fix would be simply iterating all permutations of &rule->_src->networks and Mar 02 22:59:53 &rule->_dest->networks then select mangle/PREROUTING, mangle/FORWARDING or mangle/POSTROUTING depending on whether src/dest is set/not set Mar 02 23:00:07 and adding all rules in a flat manner Mar 02 23:01:05 plus passing the currently iterated src/dest as -i / -o respectively Mar 02 23:05:22 guidosarducci: Nope, didn't change anything, unfortunately. Mar 02 23:08:57 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. Mar 02 23:09:58 guidosarducci: something like this: https://pastebin.com/8gWySLGp Mar 02 23:10:48 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 Mar 02 23:11:10 you still need to check ->_src and ->_dest for non-NULL though and possibly pass an empty list head instead Mar 02 23:11:26 or do it in a separate code branch Mar 02 23:12:14 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 Mar 02 23:14:28 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? Mar 02 23:15:16 jow: ^^ I mean non-DSCP/MARK mangle functions, the "regular" stuff... Mar 02 23:16:13 https://pastebin.com/4QQf7EfY Mar 02 23:16:28 you could give the above one a try Mar 02 23:16:52 there's not much to share with the filter cases since those are completely differently structured, chain-wise Mar 02 23:17:26 the fw3_ipt_rule_... stuff could be refactored into a helper function of course Mar 02 23:17:40 jow: that's what I expect, but doesn't stop me worrying about breakage Mar 02 23:17:53 since line 23-36 and 49+ are mostly identical Mar 02 23:18:29 the diff I pasted should nto affect any other rules Mar 02 23:23:25 jow: ok, thanks, that gives me something to play with. How best to follow up? The fw3 code is on a separate repo. Mar 02 23:24:13 try it against your use cases, see if it yields the proper result Mar 02 23:24:33 and maybe polish it a bit, consolidate redundant code etc. Mar 02 23:25:39 then you could git-send-email it with --subject-prefix="PATCH firewall3" Mar 02 23:25:45 or get back to me here Mar 02 23:27:22 need to run now, bbl Mar 02 23:27:43 jow: thanks a lot, take care Mar 02 23:43:50 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) Mar 02 23:46:32 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. Mar 02 23:47:47 great, thanks! (just need to look again where I to the patches) Mar 03 00:18:13 hmmm ML still down https://downforeveryoneorjustme.com/lists.infradead.org?proto=https Mar 03 02:26:11 build #668 of layerscape/armv7 is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/668 blamelist: ?lvaro Fern?ndez Rojas , Daniel Golle , Oskari Lemmela **** ENDING LOGGING AT Wed Mar 03 03:00:25 2021