**** BEGIN LOGGING AT Thu Mar 18 02:59:56 2021 Mar 18 04:44:51 Do board files for ath10k need to be submitted upstream to be added or can they be added here in openwrt? Mar 18 05:07:04 lmore377: I believe they can be added here. Mar 18 05:33:48 mangix: alright I'll look into it. Thank you Mar 18 07:01:26 lmore377: it's mentioned here https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles , apparently the upstream wanted them at least at some point of time. Mar 18 08:09:55 ldir: Hi Kevin, act_ctinfo question: does it decapsulate? So with a 6in4 packet, does it look up the CT info for the outer ip4 conn or the inner ip6 conn? Mar 18 08:56:40 mangix: Heh… haven't noticed that much of a difference from ld to gold, at least on this Pentium D 950… But I'll try on the i7-4770R one of these days. Mar 18 08:58:58 mangix: By the way, there's also this… https://www.phoronix.com/scan.php?page=news_item&px=GNU-Gold-Stagnate-F31 Mar 18 09:05:10 mornin' Mar 18 09:08:52 lmore377: the policy is to submit them upstream, but allowing to temporarily ship them in openwrt until they're accepted in linux-firmware Mar 18 09:09:56 lmore377: kvalo usually accepts those patches, it just takes time for them to be published formally Mar 18 10:29:14 nbd: I see you merged the musl fixes, thanks a lot! Will test soon. :) Mar 18 10:40:49 guidosarducci: short answer, no. Mar 18 11:30:36 i was asked by mtd guys to look at the following mtd patch Mar 18 11:30:37 https://patchwork.ozlabs.org/project/linux-mtd/patch/20210303155735.25887-1-michael@walle.cc/ Mar 18 11:30:49 [PATCH] mtd: require write permissions for locking and badblock ioctls Mar 18 11:30:56 they want to make sure it doesn't break user space apps Mar 18 11:31:33 it makes write permission required for MEMLOCK, MEMUNLOCK, MEMSETBADBLOCK, OTPLOCK Mar 18 11:32:21 i tried egrep -r "MEMLOCK|MEMUNLOCK|MEMSETBADBLOCK|OTPLOCK" ./package/* Mar 18 11:32:32 it shows MEMUNLOCK usage in the ./package/system/mtd/src/mtd.c Mar 18 11:33:30 we use that ioctl in mtd_erase_block() mtd_unlock() and mtd_erase() Mar 18 11:33:58 do we ever use "mtd" tool as non-root? Mar 18 11:36:27 two of above MEMUNLOCK usages are followed by MEMERASE which requires write access anywya Mar 18 11:38:31 then there is mtd_unlock() that (depending on code place) is followed by 1. nothing 2. mtd_erase() 3. mtd_write() 4. mtd_write_jffs2() Mar 18 11:38:50 cases 2, 3, 4 are earing / writing, so they need write access anyway Mar 18 11:39:33 so this may regress only "mtd unlock" calls done by non-root Mar 18 13:14:19 mangix, nbd: After the -nostdinc and -isystem fix, my RM2100 with mt76 and musl 1.2.2 is working like a charm. :) Mar 18 13:16:29 (Apart from Dropbear, that is, but it's strictly my fault, as I forgot to make clean before building the musl 1.2.2 image.) Mar 18 14:52:22 can someone paste me the output of `ubus call service list '{ "name": "network", "verbose": true }' ? Mar 18 14:53:55 jow: https://gist.github.com/Grommish/f175922f5e2216a0f4407e39ce20d83a Mar 18 14:54:05 jow: https://gist.github.com/stintel/5087a3c83c818f5f916b814a7c09c8cb Mar 18 14:54:07 ah :) Mar 18 14:57:26 interesting. latest master? Mar 18 14:57:30 jow: Nope. Dropbear failed on me, need to do a TFTP recovery later today. :P Mar 18 14:58:16 for me the triggers are set to "../init.d/network" Mar 18 14:58:37 which means they do not work and any network config change made from LuCI fails to apply Mar 18 14:58:42 took me three days to figure out Mar 18 15:01:00 Must have been "fun" to debug that one… :) Mar 18 15:04:10 yeah, turns out to be an artifact of a dirty local tree Mar 18 15:04:29 Oh, don't get me started on those… Mar 18 15:05:22 * rsalvaterra just noticed it wasn't just dropbear, tor is also pining for the fjords… Mar 18 15:13:55 jow: ubus call service list https://pastebin.com/8fE8jBZT Mar 18 15:14:01 the latest master Mar 18 16:16:09 thanks rmilecki Mar 18 16:16:17 np Mar 18 18:20:46 Build [#4](https://buildbot.openwrt.org/master/images/#builders/36/builds/4) of `mediatek/mt7629` completed successfully. Mar 18 23:04:59 ldir: I see, thanks. That's not great for those using HE for IP6. You had a long answer too? :) Mar 18 23:08:56 guidosarducci: the longer answer is that tunnels in general are difficult. think wireguard, think ssh tunnels. Mar 18 23:09:28 I really don't have a magic answer. Mar 18 23:11:16 ldir: Yeah, understood. I thought there might have been an update you're still mulling over. Mar 18 23:13:43 I wanted something that could exercise cake's diffserv capability for ingress packets, ideally without too much magic and/or learning ebpf. Inspiration arrived in the form of the conntrack firewall mark, could I stash something in there...say like the DSCP I wanted to (re)apply on ingress? Mar 18 23:14:22 ldir: In general, I would have liked to do things from BPF, but I've seen 3+ people start on CT bpf helpers in the last 3 years, and nothing merged/completed. It's getting to the point where I just might try myself (foolishly no doubt). Mar 18 23:14:40 ldir: but back then you wrote your module, so presssure dropped some... Mar 18 23:15:50 so you can change the stored DSCP at any time you like, but how that relates to the incoming packet for that connection entry may change in the case of tunnels. Mar 18 23:16:41 ldir: and yes, stateful diffserve is the best way rather that some of the overcomplicated, micromanaging messes I've been seeing. Mar 18 23:16:42 bpf is probably the way to do some decapsulation without the kernel people seeing an obvious layer violation Mar 18 23:19:36 and I honestly don't know how conntrack sees the inner vs outer (tunnel) connections. Mar 18 23:19:44 ldir: the header parsing IIRC was straightforward in the BPF helper patches, but doing the CT MARK/LABEL updates would take some more work. Mar 18 23:20:46 you probably don't need to update the CT MARK entry, but you do need to find the CT entry for the encapsulated packet. Mar 18 23:21:50 I've been out of the programming loop for a long time now. I looked at act_ctinfo.c prompted by your question and went "did I really write that?" ! Mar 18 23:22:22 ldir: from what I remember, there are separate connections for the outer ip4 and inner ip6, so doing the lookup is possible. Mar 18 23:22:38 ldir: I know that feeling :) Mar 18 23:23:25 ldir: Yikes! I have the same thought when I find something I wrote in a decades old C64 archive... Get used to it. That's the price of learning ;-) Mar 18 23:24:30 200.000+ LoC Perl project from about 15 years ago here... Mar 18 23:25:11 ^^^^^ really yikes! Mar 18 23:25:52 there's stuff in there I can't figure out at all anymore. Must've been the drugs back then Mar 18 23:26:42 jow: It's called "experience". :) Mar 18 23:27:32 jow: that's sounds like an opportunity for some deep pride or deep regret! Not understanding our own code is usually when we appreciate clarity and documentation, and "maintainabilty" means something... Mar 18 23:27:58 jow: ^^ 200K comment Mar 18 23:28:50 You must always write code thinking of the poor sod who will have to fix a bug in it 5 years from now. Because that poor sod will probably be you. :P Mar 18 23:29:30 ldir: BTW being able to write ctmark from BPF meant being able to the everything in BPF without touching netfilter. Mar 18 23:30:03 I think it's more 'use it or lose it', certainly in my case. I haven't used it 'cos I've been concentrating on using the stuff that basically keeps a roof over our heads here, so the hobby of openwrt/kernel really has to take a low priority....and some of it has been swapped out..I think to write only memory :-) Mar 18 23:31:27 ow, making progress on that Firebox M300 o_O Mar 18 23:31:54 I just learned that decompiling the OEM DTB gives a DTS full of lies! Mar 18 23:32:20 that explains why nothing I tried worked so far Mar 18 23:32:39 anyway it's late here so I'm going to turn in - see y'all later :-) Mar 18 23:35:50 ldir: nn Mar 18 23:49:47 anyone ever combined fuzzing and OpenWrt? ynezz ? **** ENDING LOGGING AT Fri Mar 19 00:01:55 2021 **** BEGIN LOGGING AT Sun Mar 21 04:22:16 2021 Mar 21 04:27:50 aparcar[m]: sure. maybe github should add a warning if a rebase would get rid of GPG signatures. Mar 21 04:40:07 support@github.com I guess Mar 21 05:17:02 can somebody plz help me solve this issue Mar 21 05:17:03 https://github.com/openwrt/openwrt/pull/3991?notification_referrer_id=MDE4Ok5vdGlmaWNhdGlvblRocmVhZDE2ODc4NzM1OTU6MTc3MjE2NTY%3D¬ifications_query=is%3Aissue#pullrequestreview-611695635 Mar 21 05:34:29 sodo: help as in merge? Mar 21 05:36:11 aparcar: see my last review Mar 21 06:10:46 Anyone want to give me a hint on this? Please? :) https://forum.openwrt.org/t/package-menuconfig-options-toggle/91750 Mar 21 06:34:24 Grommish: you don't really describe the use case or objective beyond that they're mutually exclusive. Have you considered "choice" / "endchoice" block? Mar 21 06:35:19 Grommish: ^^^ would work if one or the other *has* to be selected... more detail needed. Mar 21 06:37:28 aparcar[m]: I think I know what's going on with the x86/64 buildbot failure. That's a 5.4 build with all modules enabled, right? Mar 21 06:43:20 guidosarducci: I looked at Tristate, but not very hard. It should be One, or the other, or NEITHER, but never both Mar 21 06:43:36 So maybe a 3-part choice would be appropriate Mar 21 06:44:29 You can compile with lua, luajit or neither, but never lua AND luajit Mar 21 06:46:27 Yes Mar 21 06:46:37 Grommish: Yeah, or you need some abstraction between what you present to users and the low level config options. TBH, it's confusing to say you can use luajit without lua. Mar 21 06:47:13 guidosarducci: It's how they have it laid out.. if i build with both flag options it says No No No :) Mar 21 06:47:32 so it's either --with-lua and --with-luajit or neither flags, but not both together Mar 21 06:49:28 and since it's an engine option, I have to present the option AFAIK.. has to be built in Mar 21 06:51:31 It good news is, I can verify rust-lang works with mipsel 24kc now hehe Mar 21 06:51:35 Grommish: my point was about usability. If you simply want to pass through the raw configure options then your 3-choice option works. Mar 21 06:52:19 guidosarducci: I need to present the option, wihch I am going to read with a ifeq() check on CONFIGURE_ARGS to add to them if they are active Mar 21 06:52:26 since I don't know a better way to do it Mar 21 06:56:26 guidosarducci: https://github.com/Itus-Shield/packages/commit/044f11a85112c27909aa4ebd00d609361e52a60f Mar 21 06:57:55 aparcar[m]: if it's an ALL_KMODS build, I think the presence of new kmod-ledtrig-audio is being picked up by one of the other sound drivers. Easiest thing, and likely more robust long term would be something like: https://github.com/guidosarducci/openwrt/commit/1b26f2383fcd6cddd5d4c9b44860cc1b64785723 Mar 21 06:59:38 Build [#10](https://buildbot.openwrt.org/master/images/#builders/31/builds/10) of `layerscape/armv8_64b` failed. Mar 21 07:01:27 guidosarducci: I will probably move the ifeq checks to a separate .mk so I can keep Makefile cleaner Mar 21 07:03:21 Grommish: why not have SURICATA_ENABLE_LUAJIT depend on SURICATA_ENABLE_LUA, which makes sense to users, and deal with the mutex in your make logic? That was my point. Mar 21 07:04:07 guidosarducci: Because SURICATA_ENABLE_LUAJIT doesn't depends on SURICATA_ENABE_LUA at all, other than they both can't be on Mar 21 07:04:35 These flags enable Lua or LuaJIT support in the Suricata engine, not required host packages Mar 21 07:05:04 So it's one or the other, or neither, but not both Mar 21 07:06:07 I looked at the kconfig stuff because it's based on that, but I couldn't figure out a way to negate a package if another is selected.. I tried to with the negated DEFPENDS ON Mar 21 07:06:17 but it didn't work right, so I posted Mar 21 07:45:48 guidosarducci: choice/endchoice works for waht I need :) Thanks! Mar 21 08:46:04 guidosarducci: ping Mar 21 08:46:46 aparcar[m]: pong, just heading off soon Mar 21 08:47:07 guidosarducci: i'll compile your patch real quick and see if it fixes things Mar 21 08:47:40 aparcar[m]: OK, there's a PR with you mentioned too Mar 21 08:48:47 thanks, you're argumentation makes sense to me :) Mar 21 08:48:58 aparcar[m]: I didn't have time myself to do a full ALL_KMODS build yet either. Mar 21 08:49:12 i'm on it Mar 21 08:50:18 aparcar[m]: thanks, signing off now, will check in later. Mar 21 08:50:27 bye bye Mar 21 08:55:41 aparcar[m]: is it failing and killing the buildbot? Mar 21 08:55:58 it's breaking the build, yes Mar 21 08:56:17 aparcar[m]: If you add a IGNORE_ERRORS"m n" to the make call, it'll continue on the failed module builds Mar 21 08:56:30 instead of killign the whole thing Mar 21 08:56:48 Grommish: I think that's not the idea when building KMODS Mar 21 08:57:23 aparcar[m]: Well,, If you're building ALL kmods, it would build for ones not necessarily for the target, no? Mar 21 08:57:33 because it sets them all to M Mar 21 08:59:04 I know I had to do that for CONFIG_ALL because it set everything to M, dependancies be damned Mar 21 09:02:00 Grommish: afaik all possible targets are installed because the kernel needs some linking whatever stuff, if one of the modules fails the creation of the linking map fails and therefore the whole thing Mar 21 09:02:30 poorly explained, but it's different from compiling regular packages since kmods change the resulting kernel Mar 21 09:02:50 Gotcha :) Mar 21 09:11:33 ls Mar 21 09:13:54 nbd: morning Mar 21 09:14:38 do you have an explanation why the following prints the packages added in target/linux/mvebu/Makefile twice? TOPDIR=$(pwd) make --no-print-directory -f target/linux/mvebu/Makefile val.DEFAULT_PACKAGES Mar 21 09:23:07 nbd: okay it just needed a DUMP=1 Mar 21 09:27:18 . Mar 21 09:43:56 Hi. I have mainly been working on 19.07, but thought I should start looking at 21.02 now that it has been branched and is being prepared. I know that the two versions are incompatible due to the switch to DSA, but as far as I could see, after dsaconfig was added then writing a uci-defaults script converting from swconfig to dsa should be possible (at least for ramips) Mar 21 09:44:21 Is there somethere I am missing and there is a good reason why such a script hasn't been written, or is "just" because noone has had time? Mar 21 09:44:57 patches welcome :) Mar 21 09:45:20 Just what I wanted to hear :) Mar 21 09:46:32 I just wanted to know if there was any point in starting working on such a script or not Mar 21 09:47:26 kristrev: i think the devs decided not to facilitate migration by providing scripts Mar 21 09:50:18 Ah, ok, I see now that I also missed that dsaconfig was reverted Mar 21 09:52:49 dsaconfig isn't about migrating swconfig settings though afaik Mar 21 09:54:08 I need to develop ... something to facility upgrading the devices I am responsible for, if I can make something useful I will share it and see how it goes Mar 21 10:01:57 guidosarducci: you fixed it, thank you Mar 21 10:02:12 sodo: I just finished another review, I'll look into your issue Mar 21 10:03:08 aparcar thanks Mar 21 10:28:59 aparcar[m]: surely not interested in some proprietary stuff, just wanted to confirm my findings, that it's not possible Mar 21 10:29:52 Ack Mar 21 10:31:41 philipp64: hardware is cheap nowadays, so that's not a problem, I've integration of QEMU based devices in the works, so after that we would've broader range of arm/mips/x86 targets available Mar 21 10:32:39 philipp64: and for x86/64 real device testing I would probably go with apu4 Mar 21 10:35:07 philipp64: if you're offering help, then what is needed now is improvements of the test cases, so the test runs has increased coverage and thus higher value and probabilty to catch regressions Mar 21 10:39:17 each DUT (device under test) is connected to the test runner/executor via serial console and with WAN and LAN port (soon 2 LAN ports), so it's possible to perform testing of network setup from both WAN/LAN perspectives - DUT can thus be reached over serial and/or network during the test Mar 21 10:49:02 ynezz: what do you use as runner/executor? Mar 21 10:54:46 kristrev: you should discuss that with jow , he had his hands elbows-deep in there recently. Mar 21 10:57:49 PaulFertser: Thanks, will try to contact him Mar 21 11:07:16 My plan is to get a bit more familiar with DSA, prepare a first version of a solution and then share it on the ML. While the solution probably wont be perfect, I believe discussions are easier when there is something concrete to look at Mar 21 11:37:43 Build [#12](https://buildbot.openwrt.org/master/images/#builders/4/builds/12) of `x86/generic` completed successfully. Mar 21 11:38:40 Build [#13](https://buildbot.openwrt.org/master/images/#builders/8/builds/13) of `x86/64` completed successfully. Mar 21 12:01:45 aparcar[m]: gitlab runner Mar 21 12:05:47 In this rust-lang package, it compiles into an archive of installation files for the host_target toolchain, then uses this file in any future calls. if the package gets accepted, will the buildbot create the archives for use and download? Mar 21 12:06:49 hmm. Is there a way to set the DUID for WAN6 dhcpv6 requests? Mar 21 12:09:22 aparcar[m]: gitlab runner -> docker container -> labgrid (power on device, boot device using initramfs over tftp) -> wait for LAN up -> execute cram tests -> https://gitlab.com/ynezz/openwrt-device-runtime-testing/-/blob/master/.gitlab/testbed.yml#L51 Mar 21 12:47:56 ok guys, i need a c dev for a quick project Mar 21 12:48:07 paid work, take you a day maybe 2 Mar 21 12:51:00 Build [#18](https://buildbot.openwrt.org/master/images/#builders/1/builds/18) of `ath79/generic` completed successfully. Mar 21 13:25:47 aparcar: i fixed typo(i add ":" after pushing) but failes with same error Mar 21 15:01:49 Build [#11](https://buildbot.openwrt.org/master/images/#builders/59/builds/11) of `x86/geode` completed successfully. Mar 21 15:40:56 Build [#10](https://buildbot.openwrt.org/master/images/#builders/52/builds/10) of `x86/legacy` completed successfully. Mar 21 18:40:33 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Mar 21 20:00:50 somebody please remind me where the 21.02SNAPSHOT images are =) with thanks! Mar 21 20:04:51 enyc: https://firmware-selector.openwrt.org/ has a dropdown that includes 21.02snapshot Mar 21 20:06:19 SwedeMike: not work to give a link BUT that gave me the $clue I needed the - !! Mar 21 20:06:37 SwedeMike: now found /releases/21.02-SNAPSHOT/ Mar 21 20:06:41 thankyou =) Mar 21 20:17:57 enyc: no browser history? :) Mar 21 20:18:12 Borromini: ages ago... lots been done, different machine likely, ......... Mar 21 20:21:40 :) Mar 21 20:21:45 glad you're helping testing Mar 21 22:30:49 hmm odd. The conntrack '-f' selector doesn't seem to do anything on owrt 19.07 (trying to show only ipv6 conntrack shows everything) Mar 21 23:02:09 aparcar[m]: thanks for testing that fix. Mar 21 23:49:12 hrm dango's not here Mar 21 23:49:41 curious how to open this linksys router Mar 21 23:50:00 i really don't want to break the plastic Mar 21 23:50:50 use a torch and it will melt ¯\_(ツ)_/¯ Mar 21 23:51:15 hahaha Mar 21 23:51:33 clips 'n screws, mangix. Mar 21 23:51:56 dorf: I don't see any screws Mar 21 23:52:02 any clues in the fcc images? Mar 21 23:52:21 under stickers, or maybe just clips? Mar 21 23:52:39 a spadger or similar tool probably required. Mar 21 23:53:14 oh Mar 21 23:53:18 it does have screws Mar 21 23:53:20 well hidden Mar 21 23:53:22 that's one of the reasons I prefer buying stuff with console port Mar 21 23:56:16 o.k., https://fcc.io/K7S-03571 judging from the e8450 case, four screws on the bottom, under the stickers Mar 22 00:53:21 pkgadd: yeah. they happen to be a pain to peel Mar 22 01:01:02 damn, now i need a pinout for serial Mar 22 01:29:57 meh. can't figure out a pinout Mar 22 01:30:11 5 pins, 3 of them at 3.3V Mar 22 01:35:51 https://openwrt.org/toh/linksys/linksys_e8450#serial doesn't help? Mar 22 01:40:58 it does not Mar 22 01:41:24 that has 6 pins. this router has 5 Mar 22 02:53:49 Build [#11](https://buildbot.openwrt.org/master/images/#builders/31/builds/11) of `layerscape/armv8_64b` completed successfully. **** ENDING LOGGING AT Mon Mar 22 02:59:56 2021