**** BEGIN LOGGING AT Sat Feb 20 02:59:57 2021 Feb 20 03:08:31 lipnitsk: thanks Feb 20 03:09:31 aparcar[m]: CI's not working on 21.02 yet Feb 20 03:11:58 blocktrron: whatever happened to the effort of switching to the upstream ag71xx driver? Feb 20 03:28:12 who owns target/linux/x86? Feb 20 03:30:19 build #277 of mvebu/cortexa72 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/277 Feb 20 03:31:50 philipp64: people own targets? Feb 20 03:32:23 um... don't they? I used to be the maintainer for the geode targets like geos2 and net5501... Feb 20 03:32:52 but then there was the refactoring of everything and creating profiles vs. sub-targets and all of that went by the wayside... Feb 20 04:00:38 hmm libcap-ng is broken Feb 20 04:00:40 why Feb 20 04:15:51 only static libraries are built... Feb 20 04:34:40 build #278 of armvirt/32 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/278 Feb 20 04:46:06 philipp64, ask not about ownership but more likely for the maintainer Feb 20 04:47:36 sometimes just checking target/linux/x86 commit history might give a single dev / small dev group - especially the "switch kernel" series Feb 20 05:14:45 anyone tried building ath79 using just merged 5.10 support? Error building kmod-mdio-gpio Feb 20 05:19:59 guidosarducci: nope. something's totally broken locally. Feb 20 05:21:17 mangix: clearly :). was looking for some success stories to confirm Feb 20 05:40:35 build #272 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7622/builds/272 Feb 20 05:51:56 guidosarducci: I just built ath79 with my changes from https://github.com/openwrt/openwrt/pull/3885 Feb 20 05:55:24 lipnitsk: ok thanks, was that an "all kmods" build? I see failures now with: kmod-mdio-gpio, kmod-usb-chipidea2 Feb 20 05:57:16 yeah both of those are fixed in my branch. Feb 20 06:02:22 lipnitsk: oh I see, your first commit. Since it's more general than wireguard, maybe an separate PR/commit? Unless that PR merge is imminent? Feb 20 06:03:33 maybe it should be. Feb 20 06:03:55 I think there is still discussion to be had with wireguard, but wireguard is also one of the modules :) Feb 20 06:08:49 lipnitsk: just to be sure I'm testing a build with that commit cherry picked... Feb 20 06:13:13 lipnitsk: yup, that builds OK. Feb 20 06:14:39 lipnitsk: BTW, what are the "needs changes" for that PR? Eyes hurting, can't see... Feb 20 06:15:49 it's the decision on how to proceed with wireguard for 5.4 Feb 20 06:16:12 that's the main sticking point I think. Plus any other feedback core folks may have for my changes - I pushed quite a bit today Feb 20 06:22:33 lipnitsk: there's also the exfat module Feb 20 06:23:34 it's included with kernel 5.8 and above I believe Feb 20 06:25:09 hmmm, do we not build it at all now ? Feb 20 06:25:16 something new that needs to be added? Feb 20 06:26:50 i mean, the kmod needs to be selected Feb 20 06:27:01 and then it fails? Feb 20 06:27:58 i don't know if it does. I'm saying it needs to be set to depend on !LINUX5_10 Feb 20 06:28:11 5.10 supports exfat natively Feb 20 06:29:14 okay. I see. there is that ntfs thing too Feb 20 06:29:20 though that will be a backport Feb 20 06:30:42 well, ntfs is in the packages feed Feb 20 06:30:59 there is the paragon kernel work Feb 20 06:33:14 https://lore.kernel.org/lkml/20210212162416.2756937-1-almaz.alexandrovich@paragon-software.com/#r Feb 20 06:33:17 latest patchset Feb 20 06:33:32 probably will get merged sooner or later Feb 20 06:34:34 lipnitsk: i believe they're planning on making it a kernel module Feb 20 06:35:26 yeah but in-tree, right? Or would we still just stick it in packages? Feb 20 06:36:28 for ntfs, the module should be in base Feb 20 06:36:42 kernel modules don't really belong in packages Feb 20 06:38:52 Package jsonfilter is missing dependencies for the following libraries: Feb 20 06:38:53 libubox.so Feb 20 06:39:03 i think i need to flip a table Feb 20 06:39:10 ;) Feb 20 06:46:48 build #267 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mediatek%2Fmt7623/builds/267 Feb 20 07:31:58 mangix: nobody took the effort to add the missing workarounds / MII configuration Feb 20 07:35:37 unfortunate Feb 20 07:35:56 blocktrron: would it make sense to backport a bunch of stuff? Feb 20 07:49:40 build #6 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/layerscape%2Farmv8_64b/builds/6 blamelist: Seo Suchan , Adrian Schmutzler , Sander Vanheule , Stijn Segers , Feb 20 07:49:40 Yangbo Lu Feb 20 07:51:30 noltari: stintel: so whats the issue with urngd and bcm2708? Feb 20 07:51:57 ynezz it doesn't work with bcm2708 but it does with bcm2709, bcm2710 and bcm2711 Feb 20 07:52:44 init fails and returns ECOARSETIME Feb 20 07:53:02 timer is not usable Feb 20 07:53:12 you can't fix that Feb 20 07:53:45 IIRC mt7620 has the same issue Feb 20 07:54:36 would it be possible to modify urngd to fallback to a hw rng? Feb 20 07:55:52 does it make sense? intention was to have something very basic which can be used on all devices Feb 20 07:56:22 if the platform has hwrng it probably has enough space to run something more complete then urngd Feb 20 07:58:33 and if there is hwrng, it's usually handled via the kernel driver internally Feb 20 07:59:47 I don't know if it would make sense to leak the entropy into userspace and then feed it back from userspace to kernel Feb 20 08:02:49 are you sure that if there's hwrng it's handled internally? Feb 20 08:03:40 that doesn't make sense, considering that it takes >100s to achieve "random crng init done" Feb 20 08:04:11 this is still the case on 5.10? Feb 20 08:04:19 I've thought, that Linus fixed it already Feb 20 08:05:30 I haven't tested it with 5.10, only with 5.4 Feb 20 08:07:58 it's commit 50ee7529ec4500c88f8664560770a7a1b65db72b in kernel Feb 20 08:08:32 but it's probably using similar timer based entropy which probably doesn't work on bcm2708 Feb 20 08:09:16 "This only works when you have a high-frequency time stamp Feb 20 08:09:16 counter available, but that's the case on all modern x86 CPU's, and on Feb 20 08:09:16 most other modern CPU's too. Feb 20 08:09:18 " :) Feb 20 08:11:54 ynezz yeah, I don't think that works on ARM v6 Feb 20 08:12:52 which RPIs are using this SoC? Feb 20 08:13:06 first generation RPis Feb 20 08:13:23 B, B+, A, A+, Zero, Zero W, Compute Module 1 Feb 20 08:13:32 ah Zero Feb 20 08:14:44 anyway, haveged works and now rng-tools works too (which can be configured to use /dev/hwrng) Feb 20 08:15:05 but... should urandom-seed work if I remove urngd on this target? Feb 20 08:15:24 because I couldn't get it to work Feb 20 08:16:08 mangix: what do you mean with backport a lot Feb 20 08:16:17 the problem with haveged and rng-tools is that these are hosted in the feeds, so I can't use them to have a working setup OOB which doesn't require external packages Feb 20 08:16:54 ideally you should solve this in kernel Feb 20 08:17:07 take the entropy from hwrng and feed kernel with it Feb 20 08:17:23 no need for this kernel char driver -> userspace daemon -> kernel Feb 20 08:17:32 The upstream driver in it's current state is pretty much only usable with EWSs (and maybe AR93x7 switches), as it supports no delay configuration, RGMII clock setting as well as workarounds the RGMII / SGMII hangs Feb 20 08:17:48 ynezz any hints on how to that? xD Feb 20 08:18:31 I mean, I have the feeling that there should be some config flag to achieve that, right? Feb 20 08:19:47 I didn't wrote anything like that, but while working on urngd I've noticed, that there is framework for that in kernel Feb 20 08:20:06 I don't say it's impossible to get the upstream driver up to shape, however with testing on all SoC generations, integration of everything can be multiple weeks of effort. Feb 20 08:21:19 But to be realistic - the last time this discussion came up was over a year ago. And nothing happened in that timeframe. Feb 20 08:22:39 noltari: it's add_hwgenerator_randomness in drivers/char/random.c Feb 20 08:22:51 blocktrron: it's not like upstream hasn't been making changes. there's a flow control commit that could be backported for example Feb 20 08:23:52 if somebody wishes to backport flow control to our implementation, go ahead Feb 20 08:24:20 I was interpreting your proposal to backport stuff from k5.11 to 5.10 and use the in-tree one Feb 20 08:24:57 https://github.com/openwrt/openwrt/commit/3832403771f3319f2c95a9a084e0c3d46b7ee929#diff-603250a5c2a14bc81e820bbc3b20664a7778b985e61201aa6f6f949743f5123dR1602 is also fishy Feb 20 08:25:11 those two functions have been equivalent since kernel 2.6 days Feb 20 08:25:44 are they? Feb 20 08:25:53 last time I've checked this was not true for MIPS Feb 20 08:30:39 you're right, no idea what i was looking at Feb 20 08:31:23 But it's functionally equivalent anyways and will be removed with kernel 5.4 at some point anyways Feb 20 08:32:53 ynezz Feb 20 08:33:41 I think that what other distros are doing with RPi is to install rng-tools by default and configure it to use /dev/hwrng Feb 20 08:34:42 Perhaps we could move rng-tools from openwrt/packages to the main repo and therefore allow targets with a hw rng to include it as a default package Feb 20 08:34:45 hi guys Feb 20 08:34:52 blocktrron: ping Feb 20 08:37:14 Borromini: :D The rabbit hole has reached a new milestone Feb 20 08:37:56 Borromini: pong Feb 20 08:38:06 I've now gone to the length of recompiling the WSLv2 kernel to enable network block devices ;/ Feb 20 08:38:23 and trying to compile qemu from source so I can make the kernel mod for it Feb 20 08:38:46 blocktrron: hi. thanks for merging the EX6150 patch. could you backport it to 21.02? Feb 20 08:39:22 Borromini: yup, i can Feb 20 08:40:22 done Feb 20 08:42:55 cool, thanks! Feb 20 08:46:50 mangix: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commit;h=17f2e0f5dda638e0a6056f713797db94e5bf0042 better? Feb 20 08:52:44 build #297 of mvebu/cortexa9 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa9/builds/297 Feb 20 09:11:27 Hi, can someone add "TARGET_bcm27xx_bcm2711" at cpufreq in feed/packages/utils/collectd/Makefile please. Feb 20 09:18:44 blocktrron: sure Feb 20 09:59:26 build #293 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa53/builds/293 Feb 20 10:00:35 build #5 of ath79/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ath79%2Fmikrotik/builds/5 Feb 20 10:48:16 noltari: others doing it doesn't mean it is correct Feb 20 10:49:17 ynezz: for sure Feb 20 10:49:38 noltari: you don't see this nonsense everybody copy&pasting? hwrng -> kernel char driver -> userspace daemon -> kernel entropy feeding Feb 20 10:50:19 ynezz: yes, because it’s the easy way to do it xD Feb 20 10:51:47 I don't find commitment to the maintenance of rng-tools package easy way Feb 20 10:55:52 noltari: BTW that jitterng library has advanced, maybe it would be worth trying the latest https://github.com/smuellerDD/jitterentropy-rngd ? Feb 20 10:56:27 http://www.chronox.de/lrng.html seems to be interesting as well Feb 20 10:58:10 I plan to bump urngd to the latest in the near future as well, now waiting to the resolution (or maybe fix) of https://github.com/smuellerDD/jitterentropy-library/issues/21 Feb 20 11:04:45 ynezz: thanks, I will try the latest version of jitternet Feb 20 11:05:15 jitterng* Feb 20 11:06:49 Uh, guys… shouldn't OpenWrt set net.ipv4.conf.{all,default}.promote_secondaries to 1…? I just noticed it's at the kernel default 0. Feb 20 11:07:14 build #282 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/archs38%2Fgeneric/builds/282 Feb 20 11:08:29 At 0, if the primary address of an interface with multiple IP addresses gets remove, all the secondary IP addresses are removed too(!!). Feb 20 11:09:04 Not exactly a behaviour I'd personally expect. Feb 20 11:09:55 What would be the replacement backuip IP? the 169=.xx? Feb 20 11:10:10 Grommish: the replacement would be link down. Feb 20 11:10:28 Great for remote management surprises. Feb 20 11:10:57 Wouldn't the absence of an IP for IPv4 signify that? I geniunely don't know what it does when it drops Feb 20 11:11:05 ifdown and whatnot? Feb 20 11:11:36 It means the interface will stop having IP connectivity, basically. Feb 20 11:11:41 i thought secondary addresses were obsolete Feb 20 11:11:43 ynezz: I don't think the author and me are ever going to agree on what amount of entropy it can collect. Feb 20 11:12:05 russell--: You mean aliases. Feb 20 11:12:07 Dunno, which is why I was asking :) Its a subject i know nada about Feb 20 11:12:23 Interface aliases are obsolete, yes. Feb 20 11:12:24 eth0:1 eth0:2 etc Feb 20 11:12:58 IP aliases, however, are alive and kicking. ISPs use them to save one public IP address per client, for example. Feb 20 11:13:33 ip addr add a.b.c.d/e dev eth0 Feb 20 11:13:59 russell--: https://openwrt.org/docs/guide-user/network/wan/isp-configurations#portugal Feb 20 11:14:12 My ISP gives 4 public IPv4 per customer :D They don't advertise it though Feb 20 11:15:46 noltari: ynezz: could it be that urngd is blocking startup of rngd? that explains why START=0 "fixes" the issue with rngd Feb 20 11:16:05 when i add an address with the command syntax above, it isn't labelled as a secondary address Feb 20 11:16:08 afaict Feb 20 11:19:28 I would hope that if you have a hardware rng you would use that instead of urngd. You really want the kernel to directly use it, and as far as I understand, the kernel wants to support that. Feb 20 11:20:32 if i add an address to an interface, with, e.g. ip addr add 192.168.211.1/24 dev br-pub, i get another address attached to the interface, but no priority: https://pastebin.com/PbQ1d0Lg Feb 20 11:24:38 goddamnit my /etc/ipsec.conf is gone Feb 20 11:26:03 russell--: Right you are! That's a relief, I hadn't noticed. A bit of knee-jerk on my part. :) Feb 20 11:27:04 http://policyrouting.org/iproute2.doc.html#ss9.3 Feb 20 11:28:58 "An IP address becomes secondary if another address within the same prefix (network) already exists." Feb 20 11:29:04 ok I'm just going to revert latest changes to strongswan, that's exactly what I kept warning for, breaking existing ipsec setups is unacceptable Feb 20 11:29:13 goddamnit if you don't to everything yourself Feb 20 11:30:46 Anyone use qemu? Feb 20 11:31:06 Grommish: yes Feb 20 11:32:22 I'm trying to qemu a mips64. I'd like to look at alpine because it seems whatever.. Is there a way to use the"mini rootfile system" they have listed? Feb 20 11:32:23 here i get a secondary when i: ip addr add 192.168.211.1/24 dev br-pub ; ip addr add 192.168.211.2/24 dev br-pub ==> https://pastebin.com/Zq4PCkre Feb 20 11:32:29 russell--: I see, only within the same network. Still, I believe the default behaviour violates the principle of least surprise… :/ Feb 20 11:32:48 Remove the primary, remove them all… Feb 20 11:33:00 Debian doesn't havea mips64be version :( Feb 20 11:33:07 you shouldn't be removing them ;-) Feb 20 11:34:38 have no experience with qemu/mips64 sorry Feb 20 11:34:53 russell--: Right, I'll just file it under "don't to that", then. :P Feb 20 11:35:16 Gotcha.. Thanks :) Feb 20 11:35:56 I've got a mips debian install happening at the moment, but I want to use a mips64 aware OS thru qemu Feb 20 11:38:12 mangix: I know you love LEDs, so I just want to let you know Linux 5.10 has a driver for the Turris Omnia RGB LEDs (using the brand spanking new multicolour framework). So inclusive! <3 Feb 20 11:40:02 lol finally upstream? Feb 20 11:40:26 some qemu stuff is only nice for testing "cross plattform" and uncover some bugs in toolchain / portability issues Feb 20 11:40:49 Yeah, that's what I'm wanting to use it for Feb 20 11:40:50 Grommish: you use GNOME? Feb 20 11:41:06 mangix: Oh, yeah! But I'm not putting it in the default mvebu config, for now. It's probably better to build it as a module, not to bloat the core kernel. :) Feb 20 11:41:28 Of course Feb 20 11:41:38 mangix: no, I've got headless Ubuntu 20.04 under WSLv2 and a rebuilt kernel (under Win10) Feb 20 11:41:52 and I"m using that to build the qemu mips debian install Feb 20 11:42:06 I want to build out rustc/cargo natively in mips Feb 20 11:42:33 Lol. Best of luck. Feb 20 11:42:50 First thing is getting an Openwrt build system in Mips ;p Feb 20 11:43:04 athen waiting for it to build Feb 20 11:43:20 holy crap, this (policyrouting.org) is 20 years old: "Revised Feb 23, 2001" Feb 20 11:43:29 Anyway, alpine has mips64 I believe Feb 20 11:43:31 buildroot has mips64 CI - maybe look there too http://autobuild.buildroot.org/?subarch=mips64 Feb 20 11:44:38 mangix: they do, but I'm not sure how to use their "mini filesystem" with qemu Feb 20 11:44:52 which was the original question Feb 20 11:45:27 (which is the only mips64 version they have) Feb 20 11:45:28 mips has kernel and rootfs separated - https://openwrt.org/docs/guide-user/virtualization/qemu Feb 20 11:45:59 i remember writing and testing that mips qemu part and it worked - some years ago Feb 20 11:46:32 Right.. with the debian install, I grabbed the initrd and the kernel and it is in the process of installing ot the qcow2 vhd I made Feb 20 11:46:45 but it was for the 4k I think Feb 20 11:47:43 I tried a docker image, but I coudln't figure out how to expand the storage it had Feb 20 11:52:26 Anyway, I was going to suggest GNOME Boxes but it seems you're not running Linux. Feb 20 11:53:04 I've got a native intalled Ubuntu 20.04 on another machine Feb 20 11:53:27 But qemu lets me run it across devices Feb 20 11:54:05 GNOME Boxes uses QEMU. Feb 20 11:54:13 I'll take a look Feb 20 11:54:39 stintel: urngd should bail out on that error, as it makes no sense to be running if the host CPU can't produce usable jitter Feb 20 11:54:45 I had to build a new kernel so WSL had module support Feb 20 11:54:56 Alright, v2 of the mvebu 5.10 bringup sent. Feb 20 11:57:44 Q_: hi! :) thanks for looking into that, I really appreciate your thorough review and bringing this to our attention Feb 20 11:59:53 Q_: althought I'm probably not able to understand the issue without digging a lot deeper into it, so basicaly relying on Stephan Feb 20 12:00:51 Q_: BTW is kernel having same entropy overestimation problem? AFAIK similar functionality is being used there as well Feb 20 12:01:34 ynezz: I know the kernel is also doing something like that, I never really looked at it, it's not as easy (for me) to look at it. Feb 20 12:02:16 Q_: what would you propose as a fix? simply divide the entropy bit count by 100 ? Feb 20 12:03:32 I'm a little afraid that it would increase boot times Feb 20 12:03:59 But urngd is actually fast Feb 20 12:04:05 well, we could be afraid once we get real numbers Feb 20 12:04:37 or maybe just run that collect loop 100x times more Feb 20 12:04:52 but in the end it's probably the same result Feb 20 12:04:53 Is urngd in 19.07? Feb 20 12:04:59 yes Feb 20 12:05:28 I've been planning to do real restart tests. As in restart device, not just restart the software. Feb 20 12:05:30 Hmm. Wonder why the turris people use haveged. Feb 20 12:05:49 because omnia has hwrng? Feb 20 12:06:06 Why use haveged then at all? Feb 20 12:06:32 ah, then I'm just mistaken, I don't use either, so I've thought, that haveged can use hwrng Feb 20 12:06:41 I don't think the hwrng is functional Feb 20 12:07:04 bummer, it would be first thing to get going :p Feb 20 12:08:30 Actually I remember replacing haveged on my Omnia. Eliminated rng init warnings Feb 20 12:09:01 Or caring not ready. w/e Feb 20 12:09:33 The Omnia doesn't have a useable hwrng. Feb 20 12:10:26 What the Omnia has is this: http://ww1.microchip.com/downloads/en/devicedoc/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf Feb 20 12:11:28 Sure, it has a random number generator, but with one big caveat… Feb 20 12:11:37 Internal? Feb 20 12:11:44 grep -c rng drivers/crypto/atmel-sha204a.c -> 19 Feb 20 12:11:54 «Because there is an EEPROM endurance specification that limits the number of times the EEPROM seed can be updated, the Host system should manage power cycles to minimize the number of required updates. In certain circumstances, the system may choose to suppress the EEPROM seed update using the mode parameter to the Nonce and Random commands.» Feb 20 12:12:22 but still it should be good enough as an additional entropy source Feb 20 12:12:47 ynezz: I'd rather not use it for that purpose… Feb 20 12:13:05 you don't use just that, it's a mix of different sources anyway Feb 20 12:13:20 which makes the overal entropy better Feb 20 12:14:00 so the more the better, or it won't hurt Feb 20 12:14:17 IIRC, TurrisOS gets entropy from the ATSHA204 exactly once, at boot time. Feb 20 12:15:23 If it's used as an additional entropy source, the kernel can get entropy from it as it pleases. Not good. Feb 20 12:16:04 Wouldn't more entropy be better? Feb 20 12:16:18 build #270 of x86/geode is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Fgeode/builds/270 Feb 20 12:16:27 I'd rather stick an ath9k card in there and get more entropy from the ADC. Feb 20 12:16:35 I would say, that the quotation you've just pasted might be an issue in MCU world, where that IC is the only source of entropy Feb 20 12:17:48 ynezz: Undoubtedly. Feb 20 12:18:01 not an issue for Linux, it gets mixed with other sources anyway Feb 20 12:18:25 Hmm Feb 20 12:18:40 That ath9k thing usable at boot? Feb 20 12:18:44 wtf Feb 20 12:18:45 Sat Feb 20 13:59:54 2021 kern.notice kernel: [ 87.112662] random: crng init done Feb 20 12:18:45 Sat Feb 20 13:59:57 2021 daemon.err rngd[1008]: Initializing available sources Feb 20 12:18:56 rngd only starts *after* crng init finished Feb 20 12:19:03 even with START=00 Feb 20 12:19:04 getrandom() :p Feb 20 12:19:12 ynezz: Yes, it gets mixed, but that's not the point. The point is, how often will the kernel use it, and how long it will take until it gets broken from use? Feb 20 12:19:21 meh Feb 20 12:19:26 I'll bisect it when I return from Dubai Feb 20 12:20:50 rsalvaterra: it's just stream of random bits, which gets mixed with other random bits and in the end producing the entropy bits for the end user, AFAIK you can't tell kernel to just use one source Feb 20 12:20:57 mangix: Not until the kernel module is loaded. Because (GAH!) compat. Feb 20 12:22:55 stintel: In that case, I'd rather not use it. A source of entropy which wears down over time is special. Feb 20 12:23:05 And it should be treated in a special way. Feb 20 12:23:52 Just my 0,02 €. Feb 20 12:24:12 what do you mean? Feb 20 12:25:02 something changed between openwrt w/ kernel 5.4.43 and w/ kernel 5.4.80. with 5.4.43 I boot the Pi0W and rngd uses /dev/hwrng to feed entropy and crng init is done in ~20s Feb 20 12:25:22 with 5.4.80 this does not work anymore, rngd starts only after crng init is done already Feb 20 12:25:31 which completely defeats the purpose of running rngd Feb 20 12:25:46 the main problem is that network does not come up until crng init is done Feb 20 12:26:01 so a reboot has the device offline for almost 2 minutes instead of ~30s Feb 20 12:26:10 that's simply not acceptable Feb 20 12:27:36 It seems to have a mode where it doesn't update the EEPROM, but it all looks very weird. Feb 20 12:29:51 Q_: I see it. Chapter 8.6.14, right? Feb 20 12:30:30 Heh… but that means it'll be generating from a static seed. Not exactly what "random" means… :) Feb 20 12:30:44 rsalvaterra: what static seed? Feb 20 12:31:01 stintel: so perhaps 5.4.56, 5.4.68 or 5.4.77 I would say Feb 20 12:31:04 rngd uses /dev/hwrng - the hardware rng available in all RPi SOC Feb 20 12:31:06 stintel: Page 59: http://ww1.microchip.com/downloads/en/devicedoc/Atmel-8740-CryptoAuth-ATSHA204-Datasheet.pdf Feb 20 12:31:48 Oh, you're talking about the Pi, I thought it was the ATSHA204. Feb 20 12:31:48 stintel: I see: [ 11.042034] urngd: v1.0.2 started. [ 11.264386] random: crng init done Feb 20 12:32:08 stintel: leaning more towards 5.4.56 or 5.4.77 Feb 20 12:32:23 Q_: rpi0w cannot use jitterentropy which urngd uses, so I need rngd instead Feb 20 12:32:25 Q_: it's bcm2708 which doesn't have suitable timer Feb 20 12:33:21 stintel: see 213e1238caccfa8a0d1aa04967486cd8f3025c16 Feb 20 12:33:49 Just saying that it should be possible to run rngd before the kernel is done. Feb 20 12:33:54 [ 12.414680] urngd: jent-rng init failed, err: 2 [ 21.940740] random: crng init done [ 35.963169] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Feb 20 12:34:07 Q_: I know, it used to work, it doesn't anymore Feb 20 12:34:12 ^ is from when it worked Feb 20 12:34:45 [ 11.276469] urngd: jent-rng init failed, err: 2 [ 87.112662] random: crng init done [ 102.220810] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Feb 20 12:35:00 and here it doesn't and rngd starts only after crng init done, which seems a regression Feb 20 12:35:14 rsalvaterra: Yes, it all sounds like it's a really crappy RNG that they need to combine it with a seed. Feb 20 12:36:33 https://gist.github.com/Noltari/9e2a6201ee16574973280a641a1085dd Feb 20 12:36:49 does that look like crappy rng? Feb 20 12:37:34 stintel: Still talking about the ATSHA204. Feb 20 12:37:52 ok, I don't even know why we are discussing that ¯\_(ツ)_/¯ Feb 20 12:38:02 And testing the output of /dev/random doesn't make any sense. Feb 20 12:38:52 noltari: fyi ^ :) Feb 20 12:39:53 Actually, /dev/random became non-blocking in 5.10, I believe. It's just the same as /dev/urandom. Feb 20 12:41:48 rsalvaterra: the ef now, that sounds shitty.. I mean I get that peoples uses /dev/random way too.. hmm... "when no need to", but changing that to non-blocking because peoples are stoopid is.. stoopid.. (not that it is your fault, but you said that 😀 ) Feb 20 12:42:55 can always hook up an infnoise trng to the pi0 but meh :P Feb 20 12:42:58 Actually, it was on Linux 5.6, not 5.10. Feb 20 12:43:40 olmari: The point is /dev/random is best-effort and always has been. The blocking behaviour itself was "stoopid". :P Feb 20 12:43:55 As far as I know, it still blocks as long as it didn't get enough entropy. Feb 20 12:44:26 rsalvaterra: I don't see it that way, but that doesn't obviously even matter =) Feb 20 12:44:41 But the behaviour that made it block after getting data from it never made sense, getting data from it doesn't lower the entropy. Feb 20 12:44:48 Q_: It blocks at boot *only* until the crng init is completed. After that it's non-blocking. Feb 20 12:45:14 rsalvaterra: Isn't that what I said? Feb 20 12:45:41 Right, I misread, sorry. :) Feb 20 12:46:50 Anyway, NIST no longer accepts /dev/random as a valid source of entropy. One of the reasons /dev/random didn't get changed was that people where using it for FIPS. Feb 20 12:46:52 ynezz: thanks for that commit, I'll try reverting just that and see what gives. beats bisecting Feb 20 12:55:59 and we're back at bikeshedding Feb 20 12:56:05 ehr, yak shaving* Feb 20 12:56:20 fuck this, I'm going call of duty Feb 20 12:57:58 well GKH asked for runtime testing of -rc stable kernel releases Feb 20 12:58:30 it's gitlab CI blocking my PR to fix a typo because patches need refreshing Feb 20 12:58:34 I don't even use those packages Feb 20 12:58:50 I'm sick of this shit, every fucking time I want to do something, I ended fixing other people's mess Feb 20 12:59:20 that's software business :p Feb 20 13:05:51 gpg: Good signature from "OpenWrt Build System (PGP key for 19.07 release builds) " Feb 20 13:05:54 Good signature from "OpenWrt Build System (PGP key for unattended snapshot builds) " [unknown] Feb 20 13:06:01 sorry, wrong channel Feb 20 13:09:22 bookworm: pong Feb 20 13:09:35 Hauke: ping sure, but why Feb 20 13:10:00 bookworm: sorry worng nick ;-) Feb 20 13:10:25 wanted to anser Borromini ping, but he is not here any more Feb 20 13:14:51 Hauke: I think I can replace Borromini here Feb 20 13:15:24 Hauke: Borromini asked earlier about the sx150x driver, which is required for a few mt7621 devices Feb 20 13:15:50 it was decided to create a package for the driver, to not bloat the kernel for other devices Feb 20 13:16:33 but, the sx150x doesn't support building as a module, only as built-in, so it would have to be enabled for all mt7621 currently to properly support those two devices that use it Feb 20 13:17:52 so we were wondering how to proceed. add it to the target's kernel config anyway, or try to modularise the driver Feb 20 13:18:42 I don't think either of us understands kernel module enough to attempt the latter, though... Feb 20 13:19:01 svanheule: ok, then I would just add it to the default kernel config Feb 20 13:30:52 build #278 of kirkwood/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/kirkwood%2Fgeneric/builds/278 Feb 20 13:32:29 build #779 of armvirt/32 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/779 blamelist: Andreas Eberlein , David Bauer , Stijn Segers , Christian Lamparter , Rapha?l M?lotte Feb 20 13:32:29 Feb 20 13:34:43 is it expected that snmpd on realtek/dsa does not show the correct traffic Feb 20 13:47:38 stintel: maybe ask in #rtl83xx where the realtek network devs are hiding Feb 20 14:28:32 build #233 of lantiq/falcon is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/233 Feb 20 14:48:54 BTW I'm about to fix layerscape build ... Feb 20 15:05:37 ynezz: https://github.com/smuellerDD/jitterentropy-rngd/blob/cb13a8b136afe9e1ea1424e9e3fb50c87a6be729/jitterentropy-rngd.c#L454-L456 Feb 20 15:06:01 jitterentropy-rngd doesn't quit if init fails, but urngd does Feb 20 15:10:16 urngd --dont-care-about-entropy Feb 20 15:10:29 and then continue instead of the error Feb 20 15:14:05 https://github.com/torvalds/linux/blob/master/crypto/jitterentropy.c#L620 Feb 20 15:18:05 yes, but that's not what jitterentropy-rngd uses :) Feb 20 15:39:03 build #218 of ipq40xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq40xx%2Fgeneric/builds/218 Feb 20 16:15:14 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.2% packages reproducible in our current test framework.) Feb 20 16:38:12 build #216 of lantiq/xway_legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxway_legacy/builds/216 Feb 20 17:30:40 ynezz stintel I just found out how to fix the RPi issue... Feb 20 17:33:53 khwrngd isn't feeding entropy from bcm2835-rng because quality isn't set, so khwrngd just ignores the hw rng Feb 20 17:33:54 https://gist.github.com/Noltari/afe62c3de4b63921ab9590cf0ad29a90 Feb 20 17:34:16 after applying that patch: [ 1.014146] random: crng init done Feb 20 17:35:01 ynezz is it possible to disable urngd? for a whole target? Feb 20 17:38:43 damn 1 sec is nice Feb 20 17:45:20 build #216 of sunxi/cortexa8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa8/builds/216 Feb 20 17:55:53 stintel I'm gonna add the patch in generic. That way bcm63xx can benefit too Feb 20 18:10:51 dangole: ping Feb 20 18:41:54 adrianschmutzler: pong Feb 20 18:42:23 dangole: I'm having a build problem with fiptool Feb 20 18:42:50 https://github.com/openwrt/openwrt/commit/f59d7aab2a374d27abfdc50348d855db5560db8f#diff-554925dde8fc747c0253addfe34f36c8074d1cfe12bd4e64d9db2e058dd2f328R32 Feb 20 18:43:10 This option here is not available with the fiptool from arm-trusted-firmware-tools Feb 20 18:43:19 --ddr-immem-udimm-1d etc. Feb 20 18:43:47 So, I wonder whether I need to revert https://github.com/openwrt/openwrt/commit/84bc7d31e0a83688ef00b89b78cd124fb55e594d Feb 20 18:45:04 adrianschmutzler: yes, sounds like it :( may change the install path to something else than 'tfa-fiptool' then, eg. 'fiptool-layerscape' Feb 20 18:45:05 currently, building ls-ddr-phy fails with "create: unrecognized option '--ddr-immem-udimm-1d'" Feb 20 18:45:54 the final names in tools won't collide so far, since tfa-layerscape uses tfa-fiptool and arm-trusted... uses just fiptool Feb 20 18:46:04 in /bin I mean Feb 20 18:46:26 However, I wonder whether we get a collision since both use $(HOST_BUILD_DIR)/tools/fiptool Feb 20 18:46:31 adrianschmutzler: yes, but tfa-fiptool isn't really a descriptive name given that it's a special version with option for layerscape Feb 20 18:46:53 okay, I don't mind, so I will call it fiptool-layerscape Feb 20 18:47:10 adrianschmutzler: HOST_BUILD_DIR is set to different paths for tfa-layerscape and arm-trusted-firmware-tools Feb 20 18:47:32 adrianschmutzler: sounds perfect. are you going to commit that? Feb 20 18:47:34 ah, okay, so there is no collision? I'm not familiar with host package building ... Feb 20 18:48:17 adrianschmutzler: it's like PKG_BUILD_DIR, ie. there is a default which includes PKG_NAME, PKG_VERSION, ... Feb 20 18:48:26 ah, fine Feb 20 18:48:47 btw, how do I properly trigger clean/build for a host package via make? Feb 20 18:49:18 adrianschmutzler: by rebuilding a package which depends on pkgname/host ...? i wish i knew a better way.... anyone? Feb 20 18:49:20 i.e. for tfa-layerscape and arm-trusted-... Feb 20 18:50:44 err, wait a sec Feb 20 18:51:46 adrianschmutzler: ie. rm -rf build_dir/hostpkg/tfa-layerscape-* ; make package/tfa-layerscape/compile ; # should do the trick Feb 20 18:52:14 noltari: nice catch, really. thanks! Feb 20 18:52:51 dangole: I just tried with "make package/boot/arm-trusted-firmware-tools/clean" Feb 20 18:53:03 but that doesn't remove staging_dir/host/bin/fiptool Feb 20 18:53:05 stintel: no problem :) Feb 20 18:53:22