**** BEGIN LOGGING AT Mon Jan 20 02:59:57 2020 Jan 20 07:23:42 can anyone using LXC/LXD take a look at https://bugs.openwrt.org/index.php?do=details&task_id=2666 ? Jan 20 07:24:15 just need a confirmation (and ideally steps to reproduce it here) Jan 20 07:24:31 I would like to get it fixed in the 19.07.1 Jan 20 07:25:01 it works for me in docker (tm) Jan 20 07:25:22 my guess is, that lxd is just sending different signal to procd? Jan 20 07:26:36 it should be probably enough to boot the OpenWrt with init_debug=5 environment variable and provide the log after the `reboot` command has been issued Jan 20 09:00:48 ynezz: I could test later today, just using lxc though not lxd Jan 20 09:02:09 meh, so lxd is lxc2? Jan 20 09:02:17 I've thought its daemon Jan 20 09:03:55 ynezz: « Start a lxc container using the openwrt lxc package » is it about running lxc containers on an openwrt host? Jan 20 09:05:36 you tell me :) Jan 20 09:16:02 ok, I have asked for clarification Jan 20 09:16:53 last time I tried to run OpenWrt in a LXC container, the whole server got stuck when trying to shut down the container, I hope it improved since then :p (that was a few years ago) Jan 20 09:17:44 yes, I think, that the fix might be "different project" :) Jan 20 09:17:47 ynezz: LXC/LXD/Docker are just different ways of configuring the kernel features that allow containers to work (namespaces, cgroup, etc) Jan 20 09:18:10 yep, I assume that, each handling it differently Jan 20 09:19:10 and I assume to fully support lxc/lxd we would need to integrate https://github.com/mikma/lxd-openwrt somehow Jan 20 09:19:43 dont know if lxc/lxd is able to run docker images out of the box Jan 20 09:21:12 LXC just needs a rootfs (in a LVM volume or just a directory) Jan 20 09:21:48 I think you can just untar http://downloads.openwrt.org/releases/19.07.0/targets/x86/64/openwrt-19.07.0-x86-64-generic-rootfs.tar.gz and it will work Jan 20 09:21:53 I don't know aobut LXD Jan 20 09:22:41 ubiquiti m5hp bullet rebooted itself after 9 days of uptime with nothing on serial console Jan 20 09:22:49 ynezz: the only openwrt-relevant thing is that they seem to patch procd? https://github.com/mikma/lxd-openwrt/blob/master/patches/procd-master/0001-state-support-reboot-of-containers.patch Jan 20 09:23:00 and bunch of init scripts Jan 20 09:23:40 zorun: so under the OpenWrt in QEMU, I just need `opkg install lxc; wget foo.tar.gz; untar foo.tar.gz; lxc run foo?` Jan 20 09:25:06 zorun: I remember there were some kernel bugs when I initially started using lxc somewhere last year but they have since been fixed afaict Jan 20 09:26:10 zorun: unless I'm able to reproduce the issue, it doesn't exist, so the fix is questionable as well Jan 20 09:26:24 zorun: and I don't want to break currently working Docker support as well Jan 20 09:26:39 ynezz: for LXC you need to create a configuration file, see lxc.conf Jan 20 09:26:53 zorun: and I've probably better fix for that reboot issue (if it's issue in procd) https://gitlab.com/ynezz/openwrt-procd/commit/aa8689ccdff0124f3d477f86433496aeb2c49d24 Jan 20 09:27:56 zorun: that was my point, provide me with some exact steps I could use to reproduce it, thanks :) Jan 20 09:31:22 ideally to that bug report, so others could eventually test/fix it if I suddenly dissapear Jan 20 09:34:16 yeah I'm doing just that Jan 20 09:40:22 hi all, is there any reason why perf is only in openwrt/lede 17.04 release? Jan 20 09:49:04 indy: @KERNEL_PERF_EVENTS Jan 20 09:50:20 indy: in other words, you need custom kernel in order to get working perf Jan 20 09:51:09 indy: this kernel config option is probably not enabled by default for size reasons Jan 20 09:51:59 orning Jan 20 09:54:18 ynezz: done, but I couldn't get a useful log: https://bugs.openwrt.org/index.php?do=details&task_id=2666 Jan 20 09:54:33 what component is supposed to react to DBGLVL? procd? Jan 20 09:54:54 yes Jan 20 09:55:20 ok, it probably needs to go in the configuration then Jan 20 09:55:56 ynezz, even for x86-64? Jan 20 09:56:53 indy: nobody would object (I would welcome it) against such patch Jan 20 09:57:38 indy: most of developers simply use custom kernel/images, so the perf is just bundled in those custom images Jan 20 10:01:05 blogic: "21:55:51 < Hauke> jow: ynezz: I am still prepareing the answer, I am bussy with some other stuff" on Friday Jan 20 10:01:10 err, sorry Jan 20 10:01:20 perf probably got disabled last time it broke, and hasn't been turned on again. Jan 20 10:01:40 sounds very possible, perf is one of those things that constantly break Jan 20 10:01:44 like gdb and strace Jan 20 10:01:44 it's famous for breaking horribly on every teensy breath of wind on the kernel Jan 20 10:02:04 but it woudl be nice to have working :) Jan 20 10:02:07 eventually you get tired of it and disable it in your config Jan 20 10:02:08 +1 Jan 20 10:04:04 I constantly use perf Jan 20 10:04:19 poser Jan 20 10:04:19 yay? guess it works this week then? Jan 20 10:04:27 ynezz: on what target? Jan 20 10:04:30 or rather have it in my configs Jan 20 10:05:20 my staging configs I currently build: mt7621, ath79, imx6, x86 Jan 20 10:07:02 my x86 https://privatebin.net/?1c09364253e78c86#FmkAPsY7ii4kffAhqsCv8UpvgzAPXQ89ArNqnooS43A8 Jan 20 10:08:16 oh, please note, that "#CONFIG_KERNEL_PERF_EVENTS=y" is disabled for a day or so as I wanted automatic rebuild Jan 20 10:09:08 ynezz: what did you want to see exactly in the procd logs? it just seems to shutdown Jan 20 10:09:12 indy: ^^^ the actual answer Jan 20 10:09:45 zorun: which state is triggered Jan 20 10:10:39 karlp: one option would be to decouple the perf version from the kernel version and stick with something that works Jan 20 10:11:04 that's what I'm doing on gentoo Jan 20 10:12:12 been on perf-3.12 for 4 years, perf-4.4.4 for another year, perf-4.9.13 for few months and perf-4.14.33 since early 2019 Jan 20 10:13:29 and I think, that we shouldn't do that, we should report the fixes/problems upstream Jan 20 10:14:35 if it breaks often, just add some periodic CI job and build new kernel with all ours SDKs Jan 20 10:14:46 and report the problems back ASAP Jan 20 10:15:14 puting our head into the sand doesn't make sense :) Jan 20 10:16:12 in an ideal world, yes Jan 20 10:16:38 but sometimes you want to get shit done instead of reporting bugs Jan 20 10:17:52 that. Jan 20 10:17:59 well, does it break right now? or is this moot? Jan 20 10:18:14 show me pls, I'll fix it Jan 20 10:18:17 its always fn if you want to fix an issue and end up debugging the toolchain Jan 20 10:19:19 yes, but fixing it at right place saves you (and other people) time next time Jan 20 10:21:41 karlp: I just didn't found time to fix that missing kernel config symbol properly Jan 20 10:26:04 so in other worlds, perf builds fine, but since I'm sometimes playing with BPF/jail I've added not so currently common kernel config options, which in turn leads to missing kernel config symbols, thus Y/N/m questions during kconfig step which is unwanted if you're bisecting build brekage automatically Jan 20 10:28:04 other than that, I'm using those staging configs to build test (sometimes run test) every time before pushing Jan 20 10:28:15 so I assume, that I would notice the perf breakage Jan 20 10:29:09 it's likely, that I'm doing it wrong, so looking forward to see the reproducible build breakage of perf, so I can fix it adjust my staging testing config Jan 20 10:37:48 jow: Re: poser -> it doesn't mean, that building = using :) Jan 20 10:39:41 ;) Jan 20 10:41:03 I'll try to remember to enable it again in my next x86/64 build Jan 20 10:45:04 Mornin' all Jan 20 10:45:19 'lo xback Jan 20 10:45:21 it's push-Monday today .. kernel bumps on the way Jan 20 10:46:12 just 1 .. 2 more issues .. and I should be able to push 5.4 generic to master Jan 20 10:46:33 nice Jan 20 10:46:39 * stintel looks forward to see how it breaks perf :D Jan 20 10:46:51 party pooper ;-) Jan 20 10:47:17 xback: good morning to you too ;) Jan 20 10:47:31 stintel: that's what I meant ;-) Jan 20 10:53:06 blogic: The patches from roger (ath79 support for Mikrotik) works really well Jan 20 10:53:44 blogic: I'll do final testing for that later today. But all looks good, so this would be a huge improvement in order to phase-out ar71xx entirely Jan 20 10:54:43 It should be easy(er) to port all other Mikrotik devices now Jan 20 10:54:44 when I ran make oldconfig on my apu2 .config I got question for CONFIG_PKG_ASLR_PIE_ALL, I've enabled it, and seems px5g-standalone and ppp don't build with it. can I push https://git.openwrt.org/289bf744 https://git.openwrt.org/9d396134 for this? Jan 20 10:55:33 stintel: I'm not sure about that ppp one Jan 20 10:56:09 it's network service, so it could possibly leak some information over network, thus defacing the whole purpose of ASLR Jan 20 10:56:12 because it's a network component. probably better to fix it Jan 20 10:56:16 yep Jan 20 10:56:28 ok Jan 20 10:57:31 which reminds me, that we should revisit the auto restart of network exposed services Jan 20 10:58:07 it makes no sense to have ASLR if one could try his luck indefinitely (or more then once) Jan 20 10:58:38 and I still need to provide info for Daniel about the wifi reconfig stuff breaking wifi client reliability Jan 20 10:58:53 it's written in red on my whiteboard so there's a start =) Jan 20 11:00:07 and about that px5g breakage, just report it on bugs, its better to fix it as well Jan 20 11:00:41 ok, then I just keep them locally for now, so I can actually build images Jan 20 11:00:46 thanks for the feedback Jan 20 11:01:30 I was thinking that it might make sense for x86/64 and other targets with plenty storage, we could at some point default to CONFIG_PKG_ASLR_PIE_ALL ? Jan 20 11:01:42 but then we'd need to fix those bugs of course Jan 20 11:22:22 remember the selfsigned ssl cert discussion to enable web interface via https by default? Seems Netgear tried :P https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9 Jan 20 11:24:41 LOL Jan 20 11:25:57 hah, exactly a scenario I described even =) Jan 20 11:32:30 only way I could see valid ssl in routers would be to include LE/ACME and after that there is then trickery of what domain and how to really reach that... can't give one in this scenario.. so would only complicate things alot and not even solve Jan 20 11:32:50 ..in openwrt Jan 20 11:32:51 its all crap which only the browser vendors can solve Jan 20 11:33:00 but it usually gets shrugged away Jan 20 11:33:34 that probably the reason why mobile apps gained popularity for router configuration Jan 20 11:33:45 you can hardcode your certs there now :) Jan 20 11:34:06 well... issue itself is SSL working model... next issue is indeed the notion of making plain http yell more and more =) Jan 20 11:35:26 mm... also some method of secret storage and whatnot.. distribution of private key is indeed the root-issue within valid ssl in default router image Jan 20 11:39:24 * karlp blames the browser vendors still. Jan 20 11:39:46 security is hard, lets go shopping :) Jan 20 11:42:25 Well... Thing also is that for internet it isn't THAT bad of thinking model (http not being secure, which it indeed is not), but ot does not cater well to these kind of things like new home router that may or may not have internet access from 0 =) Jan 20 12:03:54 xback, mornin' Jan 20 12:04:08 any news on 5.4 for mvebu? Jan 20 12:04:14 stintel, o/ Jan 20 12:04:18 nitroshift: o/ Jan 20 12:14:16 so that UX helper regarding the SSL cert is not doable? Jan 20 12:15:26 first time connect to :80 redirects you to :80/sslpal -> "explain the next possible SSL validation error" [OK, I'm educated now let me in] -> :443 Jan 20 12:15:30 ynezz: it is, no worries Jan 20 12:15:57 I was just amused to see the "screw it, let's ship private keys" approach tried in practise Jan 20 12:16:18 assuming 80 is never considered as red as self-signed cert is that would work Jan 20 12:17:40 jow: it's interesting, that they don't do the same for bootloaders :p it would make factory images easier... Jan 20 12:18:32 anyway, that timeline is quite rush "14.1. initial contact" -> "19.1. no response, full disclosure" :D Jan 20 12:19:13 but they deserve it Jan 20 12:20:04 olmari: LE/ACME is for limited period of time, like 3 months, isn't it? Jan 20 12:20:36 yes Jan 20 12:20:52 although releases every 3 months should be doable :p Jan 20 12:20:56 lol Jan 20 12:21:04 that doesn't make people update their devices though ;) Jan 20 12:21:08 They didn't say no contact, but no viable contact.. if answer was "we only talk through bugbounty program" which has insane terms... Jan 20 12:21:10 ynezz: yep, and while it optimally would solve 1 issue, it would create 1 or 2 other Jan 20 12:21:23 stintel: opkg install openwrt-le-cert :) Jan 20 12:21:25 I did mean owrt would generate LE-cert on the boot.. Jan 20 12:21:32 ah Jan 20 12:21:42 not diable without a domain Jan 20 12:21:45 *doable Jan 20 12:21:57 and I don't feel like operating an openwrt ddns service Jan 20 12:22:09 but that gives other issues, like can't really use one domain, but pretty much random subdomain and bleh Jan 20 12:22:37 like said, it will solve A problem, but gives many more in itself, so... yeha Jan 20 12:22:51 there is no such luci app already? Jan 20 12:22:57 :) Jan 20 12:24:18 ynezz: for? issue is not the thing being able to make LE certs... it is "first boot" and access to router webui and it's valid SSL (together with fact that browsers treats http more and more as red flag) Jan 20 12:24:58 ah, first boot Jan 20 12:26:22 right time for that mobile phone application? :p would that solve it? Jan 20 12:26:42 it's just a problem of the browser UI, so I assume, that yes Jan 20 12:26:47 that, together with some cloud subscription plan Jan 20 12:29:42 and ddns is the yacky-option? ;D Jan 20 12:35:45 I'd really hope there would be an method to (without insane effort) become CA for these kind of specific thing.. would solve stuff quite happily in long run Jan 20 12:37:51 ..well I don't know would it change the methods from LE that much, but ideas... ideas everywhere Jan 20 12:54:22 again, the _browsers_ could make this less suck, but they don't seem open to it. Jan 20 12:57:00 how exactly? Jan 20 12:58:06 not making the experience of self signed certs so disastrously unuserfirendly Jan 20 12:59:35 out of curiosity, do you've an idea how this could be improved? Jan 20 13:01:55 not having them warn at all? Jan 20 13:02:08 I don't trust a CA anymore than anyone else. Jan 20 13:02:32 CA certs just mean that _hopefully_ I have some sort of admin rights on the dns for the domain, and $20. Jan 20 13:03:24 but if you're talking baout things like "routerlogin.net" or similar magic names that resolve toa local address, or even just an IP, why should I be getting a scary warning at all? Jan 20 13:05:23 With validation, there is at tje very least exactly someone that has validated an domainname... so no other can mitm or pretend.. in really short explanation... Jan 20 13:09:36 there is another problem with enabling https by default, aside from the obvious certificate issues. right now, openssl is the only option for wpa3 support - but it's also the largest option, weighing around 1 MB, that's significant on devices with 8 MB flash, so defaulting to mbedtls/ wolfssl instead of wpa3 makes it 'harder' to add WPA3 support. it's just not ideal Jan 20 13:10:39 How does those 2 relate? Jan 20 13:12:39 well, the only sane option for WPA3 and https would be openssl for both (luci-ssl-openssl && wpad-openssl). if wpa3 is not necessary, mbedtls would do Jan 20 13:13:25 you just make that harder for joe sixpack to accomplish, if luci-ssl (mbedtls) is already preinstalled Jan 20 13:14:33 it means making suboptimal choices, while not preinstalling any tls provider leaves that open Jan 20 13:17:04 a hypthetical wpad-mbedtls (or hostapd gaining standalone support for wpa3) would solve that (but I don't see that happening anytime soon) Jan 20 13:37:08 luci-ssl is available without openssl too unless something is changed very recently... wpa3 is then what it is Jan 20 13:38:30 ynezz, karlp afaik perf has releases out of kernel - https://mirrors.edge.kernel.org/pub/linux/kernel/tools/perf/v5.4.0/, i would expect it will need kernel headers Jan 20 13:40:34 btw is somewhere guideline how to generate and use -dev package? Jan 20 13:41:51 along the lines of debian or fedora -devel? we don't really have them, we just InstallDev the dev headers with the package. Jan 20 13:45:59 i spotted some -dev packages Jan 20 13:46:58 but not yet dived into makefiles to play with that Jan 20 13:49:28 got an example? Jan 20 13:49:47 only things I could think of would be if someone was trying to build a separate package to let people build on the target? Jan 20 13:51:30 like libxml2-dev is for installing things onto the target so you can build there, but this is not at all common Jan 20 13:51:32 :q Jan 20 13:53:09 zz Jan 20 13:53:28 let say i have library and application which rely on boost, with container openwrtorg/sdk i can build it, but it will rebuild all the time boost and everything Jan 20 13:54:32 if i commit to image everything after build it also has lot of craps in build directory itself, which i don't need Jan 20 14:09:39 karlp, what about debug symbols? are they stripped to /dev/null or are they present in sdk somewhere? Jan 20 14:11:19 meant to still be in build-dr or staging dir, I never remember which, you can see how the scripts/remote-gdb sets up the paths Jan 20 15:07:48 * indy just have perf devels/maintainers on wire and pointing them to openwrtorg/sdk+rootfs Jan 20 15:42:18 blogic: If you have some time, can you have a quick look at my mediatek patches here: https://patchwork.ozlabs.org/project/openwrt/list/?series=153089 Jan 20 15:46:54 ..in general I think sanest answer to https in router is what yakatz gave in the gist mentioned earlier... Jan 20 15:46:54 "The proper solution is what Verizon does. They have every gateway use a self-signed certificate. When you go to the IP address with http, it shows a message warning you that it will redirect to https and you will get a certificate error. If you don't understand that, you probably shouldn't be accessing the router interface." Jan 20 16:01:14 right, and only required because no-body can get the browser vendors to play along Jan 20 16:03:01 eh.. forget browser vendors already... internet cert trust model is what it is, pointless to fight against windmills now after 20 yeares from official one and some 6 more from first show =) Jan 20 16:05:09 I fully see why this method was chosen, even if I wouldn't agree with everything... self-signed you lose the exact trust model current method does, no matter do you personally trust any CA or not :) Jan 20 16:06:43 and I consider such things as router default page being pretty corner case in grand sheme of things, while ofcourse some alleviation model would be cool... but sitll not ultimately needed Jan 20 16:09:09 speaking of certs https://gitlab.com/ynezz/openwrt/-/jobs/409160612 Jan 20 16:10:49 yay =) Jan 20 16:36:29 does ubus/procd do any batching of events? I've got reload_config being called twice, and I've added prints into it showing it detects two config changes, and sends two ubus events, so I kinda expect the process to be restarted twice, Jan 20 16:36:51 but I see it.... just not. the final uci config is the same as the initial config, so this is... nice, but I don't know why it works at all. Jan 20 16:38:43 procd will coalesce events Jan 20 16:39:47 what's the timeframe for that? Jan 20 16:40:23 procd coalesces to a single event, and because all the files are properly registered with procd, _procd_ is now aware that there's no change and it can ignore the reload_config call? Jan 20 16:41:25 (this is awesome, I just didn't know, and I'm only discovering it because some _other_ things of mine seem to have been working for ... not the reasons I imagined htem) Jan 20 16:53:44 yes, this sums up the behaviour... as for the timeframe ... iirc its not easy, afair the coalescing is due to the way ubus evetns are received and the event loop is functioning Jan 20 16:56:23 oh joy. Jan 20 16:57:26 hi, is there an easy way to toggle an SPI slave select? Jan 20 16:57:42 for locating this pin on the board Jan 20 21:35:15 build #69 of oxnas/ox820 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/oxnas%2Fox820/builds/69 Jan 20 22:27:27 build #67 of ar7/ac49x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ar7%2Fac49x/builds/67 Jan 20 23:32:08 build #87 of ramips/mt76x8 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt76x8/builds/87 **** ENDING LOGGING AT Mon Jan 20 23:42:21 2020 **** BEGIN LOGGING AT Mon Jan 20 23:44:18 2020 **** ENDING LOGGING AT Mon Jan 20 23:48:17 2020 **** BEGIN LOGGING AT Mon Jan 20 23:50:16 2020 Jan 21 00:01:13 build #84 of armvirt/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F64/builds/84 Jan 21 00:04:24 build #86 of lantiq/xway is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxway/builds/86 Jan 21 00:31:20 build #84 of brcm47xx/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm47xx%2Flegacy/builds/84 Jan 21 00:32:02 build #88 of zynq/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/zynq%2Fgeneric/builds/88 Jan 21 01:02:27 build #91 of bcm53xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/bcm53xx%2Fgeneric/builds/91 Jan 21 01:02:30 build #91 of brcm2708/bcm2710 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2710/builds/91 Jan 21 01:06:18 build #91 of omap/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/omap%2Fgeneric/builds/91 **** ENDING LOGGING AT Tue Jan 21 02:59:56 2020