**** BEGIN LOGGING AT Fri Nov 20 02:59:57 2020 Nov 20 06:01:58 mangix: I'd merge it now and tomorrow we know more Nov 20 06:18:31 aparcar[m]: I missed context. This garbage kernel keeps causing reboots Nov 20 06:47:01 zorun: the driver is crappy, either people complain about QinQ not working or port tagging not working Nov 20 06:47:51 zorun: however the DSA driver is almost ready at which point we keep the current state and fix the port taggibng via QinQ Nov 20 06:47:56 zorun: however the DSA driver is almost ready at which point we keep the current state and fix the port taggibng via DSA Nov 20 09:15:42 blogic: I guess DSA will not be backported to 19.07? Nov 20 09:20:32 zorun: Heh… I'm still hoping we'll get DSA in ath79 for 20.x… :P Nov 20 09:21:10 yeah, so no chance to backport such a big change Nov 20 09:21:45 blogic: another regression introduced by this change: https://bugs.openwrt.org/index.php?do=details&task_id=3457 Nov 20 09:22:41 blogic: I think it's safer to just revert the commit before 19.07.5 Nov 20 09:24:43 rsalvaterra, o/ Nov 20 09:25:15 nitroshift: o/ Nov 20 09:32:40 zorun: anyone can propose patches, right? :) Nov 20 09:32:48 Ok, something's wrong in master with DSA. Nov 20 09:33:11 I just built an image and… Nov 20 09:33:14 Fri Nov 20 09:30:34 WET 2020 upgrade: The device is supported, but the config is incompatible to the new image (1.0->1.1). Please upgrade without keeping config (sysupgrade -n). Nov 20 09:33:14 Fri Nov 20 09:30:34 WET 2020 upgrade: Config cannot be migrated from swconfig to DSA Nov 20 09:33:23 … WTF? This is already DSA! Nov 20 09:36:45 and what's wrong with that? Nov 20 09:36:49 ynezz: that's an overstatement Nov 20 09:37:09 rsalvaterra: which device? Nov 20 09:37:32 Redmi AC2100 (mt7621). Nov 20 09:37:48 the story there is interesting Nov 20 09:37:59 The MT7530 switch is DSA. Nov 20 09:38:20 yeah I know. I was partially responsible for it Nov 20 09:38:50 mangix: so you expect, that anyone is going to revert that commit in the stable release without any prior discussion? Nov 20 09:38:55 I'm all ears (eyes). :P Nov 20 09:39:24 ynezz: I was responding to your earlier comment Nov 20 09:39:40 mangix: ok, didn't get it, which one? Nov 20 09:41:06 rsalvaterra: the story is that with 19.07, several mt7621 devices have issues with the ethernet driver locking up the device. my suggestion was to replace the openwrt driver with the one used upstream. that necessitated the move to DSA. Some are mad some are happy. Overall, easier maintainability Nov 20 09:41:41 rsalvaterra: swconfig to DSA migration is quite complex task, nobody so far was interested in that implementation, so it has to be done manually, so you at least get that notice and can decide yourself Nov 20 09:41:51 ynezz: patch proposal one. I have 36 patches on the mailing list currently. Proposing != action. Nov 20 09:42:01 day has only 48 hours Nov 20 09:42:12 ynezz: good point ;) will do Nov 20 09:42:31 actually the ramips 5.4 moved several drivers to the upstream ones, which is quite nice Nov 20 09:42:37 *5.4 bump Nov 20 09:43:19 mangix: Sure, what I don't understand is why sysupgrade complained today about DSA, when it didn't yesterday or the day before. I have this device since Tuesday and the very first image I installed was already DSA-based. Nov 20 09:44:52 Actually, I got this Redmi AC2100 for three reasons: a) I wanted to play with MT7621; b) The switch was already DSA-based; c) It's cheap as chips. Nov 20 09:46:52 What I wasn't expecting is mt7603e and mt7615e only allowing 4 VIFs, but I can live with that. :P Nov 20 09:49:07 most mt7621 i've owned had messed up wifi callibration, which ruins the performance of the interface Nov 20 09:49:23 actually that was only one device Nov 20 09:49:30 mangix: messed up how? Nov 20 09:49:46 russell--: not present or all 0s. I don't remember Nov 20 09:49:55 how did it happen? Nov 20 09:50:14 indiegogo campaign Nov 20 09:50:19 ah, lol Nov 20 09:50:21 the guy didn't pay to get it done i guess Nov 20 09:50:29 mangix: If caldata was messed up, the vendor firmware would have the same problem, not just OpenWrt, right? Nov 20 09:50:57 well, vendor firmware was some weird mediatek SDK based build Nov 20 09:51:06 LOL! My only experience with Indiegogo has been wonderful (Turris Omnia). :P Nov 20 09:51:35 at some point i stumbled across a description of the mediatek factory partition format, but i don't know where it went and haven't found it again after some looking Nov 20 09:51:48 I have one as well. Unfortunately I spent too much money on it. Now the wifi is ruined. Don't feel like spending money to fix it. Nov 20 09:52:32 mangix: You can't ruin Wi-Fi on an Omnia. Just replace the cards, pigtails, antennas, whatever. Nov 20 09:52:33 well, more like the wifi gets unstable aftet 2 days uptime Nov 20 09:52:53 rsalvaterra: that's exactly what i did. now I need new pigtails and everything Nov 20 09:54:44 (Oh, my…! I just realised the Redmi AC2100 is able to hit 27 dBm in the 2.4 GHz band and 27 dBm in the 5 GHz band.) Nov 20 09:54:58 in other news, it amuses me how people take OpenWrt patches and apply them to non-OpenWrt platforms Nov 20 09:55:10 *26 dBm in the 5 GHz band, I mean. Nov 20 09:55:31 * mangix googles Nov 20 09:56:10 mangix: I find more amusing receiving emails from patches which I wrote in 2016 being applied to kernel trees I never knew existed, in 2020. Nov 20 09:57:17 does this seriously not have any ethernet ports? Nov 20 09:57:33 ah nvm. 4 Nov 20 09:57:50 that's 2 less than the omnia Nov 20 09:58:07 this reminds me why I hate mt7621 Nov 20 09:59:22 I never saw anyone complaining about the 3 ports on the APU2C4, for example… :) Nov 20 10:01:31 mt7621 still is not using the upstream MMC driver. Unfortunate Nov 20 10:01:55 I remember the OpenWrt one being quite unstable Nov 20 10:02:09 same with the USB driver Nov 20 10:02:19 * mangix finds his bottle of Ouzu Nov 20 10:03:41 * russell-- has some APU4's coming because the APU2 only has three interfaces ;-) Nov 20 10:06:38 mangix, my dir860l with mt7621 had a semi-flakey USB (some devices didn't work) a long time ago, i haven't checked recently Nov 20 10:07:43 there's a local openwrt patch for ramips for the USB. There are reports that it's unnecessary. I don't remember if I tested removing it. Nov 20 10:08:03 russell--: I was wondering, is the APU4 also using separate NICs like the APU2, or is there a built-in switch? Nov 20 10:08:27 zorun: seperate nics, although the connectors are all i a block Nov 20 10:08:36 ah ok, thanks, Nov 20 10:08:36 so you need a new case :-) Nov 20 10:08:43 yeah this is why I was wondering :) Nov 20 10:09:41 apu4d4 = 4 i211AT LAN / AMD GX-412TC CPU / 4 GB DRAM / dual SIM Nov 20 10:09:52 https://www.pcengines.ch/apu4d4.htm Nov 20 10:18:57 still no news of a newer APU with faster CPU :/ Nov 20 10:19:12 except for this old thread about APU5: http://pcengines.info/forums/?page=post&id=7D919FB8-C4BB-4C33-B47B-F8F53E01600D Nov 20 10:22:13 yeah, the cpu is getting old. i am using mine strictly as a gateway on a gigabit fiber service, and it does that nicely Nov 20 10:22:57 i have an apu2 now, since 2016-ish, same cpu Nov 20 10:26:36 yes we also have lots of apu2 (3 ports is enough when you have a switch to untag VLANs) Nov 20 10:27:10 it's generally fine when doing pure forwarding, but wireguard or even PPPoE will bring it to its knees Nov 20 10:27:38 actually, PPPoE is slower than wireguard on these devices :-) Nov 20 10:27:58 !? why Nov 20 10:27:59 mostly because of single-threading vs multi-threaded I guess Nov 20 10:28:19 but pppoe just has to strip 8 bytes off or something Nov 20 10:28:27 unless its a userspace implementation? Nov 20 10:28:31 well now that I think more about it, we are doing wireguard *on top of* PPPoE Nov 20 10:28:38 ohh Nov 20 10:28:43 so no wonder it's slower Nov 20 10:28:49 A+B vs B Nov 20 10:29:06 makes sense Nov 20 10:29:46 i switched from orange to bouygues for pretty much the exclusive reason of avoiding pppoe Nov 20 10:29:51 yes, but the bottleneck clearly seems to be on the pppoe side Nov 20 10:30:00 huh, interesting Nov 20 10:30:14 not sure if it's userspace or offloaded to kernelspace though Nov 20 10:30:21 zx2c4: you know that Orange is no longer doing PPPoE for fiber :) Nov 20 10:30:27 i have pppoe here, but haven't noticed performance problems Nov 20 10:30:28 I believe most ISPs around here got rid of PPPoE, fortunately. Nov 20 10:30:29 reaaaaaaaly? Nov 20 10:30:34 yeah, for several years already Nov 20 10:30:37 wow Nov 20 10:30:41 still vlan 835? Nov 20 10:30:48 I mean, you can still do it (although at some point they will probably drop support for it) Nov 20 10:30:55 but DHCP is the default now Nov 20 10:30:57 yes Nov 20 10:30:59 oh awesome Nov 20 10:31:09 do you have to send funny strings in dhcp or does it work OOTB? Nov 20 10:31:19 not OOTB of course :) Nov 20 10:31:30 it requires fiddling with weird ethernet priority flags Nov 20 10:31:30 depending on which box Nov 20 10:31:36 see lafibre.info Nov 20 10:32:03 Im running something like `busybox udhcpc -i internet -f -p /run/udhcpc.pid -r 176.123.123.123 -V "BYGTELIAD" -s /bin/true` for bouygues Nov 20 10:34:46 I don't remember the details but I see things like "vconfig set_egress_map" and "iptables -t mangle -A POSTROUTING -o $IFACE.832 -j CLASSIFY --set-class 0000:0001" in the place where I setup this long ago Nov 20 10:34:52 and a "rfc3118-authentication" DHCP option Nov 20 10:34:54 oh interesting... Nov 20 10:35:22 anyway, it's off-topic here and well documented https://lafibre.info/remplacer-livebox/remplacer-la-livebox-sans-pppoe/ Nov 20 10:35:51 ynezz: given that the logs link is totally dead, can this be set up? https://freenode.logbot.info/ Nov 20 10:36:41 mangix: seems to be working? https://freenode.irclog.whitequark.org/openwrt-devel/2020-11-20 Nov 20 10:36:56 it's even real-time, wow Nov 20 10:37:11 weird. I was getting 502 errors earlier Nov 20 10:37:35 planned downtime I guess Nov 20 10:56:49 zx2c4, zorun: I'll be switching to FWA technology soon, due to no better choice. I'll have to do pppoe on my openwrt router, they bring me their own device that sits between me and the antenna Nov 20 10:57:01 on the ruff Nov 20 10:57:36 I would like so much if I could do a dhcp with a single openwrt based device with no intermediate ones Nov 20 10:57:53 guess I'll have to wait for SFP fiber and FTTH?? Or am I missing something? Nov 20 10:59:30 I don't know FWA technology Nov 20 11:00:05 zorun: me neither, my ISP seem to use it's own frequency band, 28 ghz, for the link ... Nov 20 11:00:26 will pppoe be a major bottleneck in performance' Nov 20 11:01:03 and wanted to know if there is a way I can discover the optimal MTU - I admit i never explored / understood the MTU thing too much in PPP world. Nov 20 11:07:28 ah, FWA means "Fixed Wireless Access", I thought it was the name of an ISP Nov 20 11:07:58 pppoe is generally a bit slow, yes, but you have to test/benchmark Nov 20 11:11:16 zorun: yeah, sorry for not specifying that. FWA is the technology, the provider is EOLO. yeah, I'll try to do my best. Nov 20 11:12:20 zorun: I am blind user, so having an openwrt box is very very nice and useful, let alone all the advantages of openwrt. so I try to minimize what's between openwrt and the ISP, not a easy task you know :D Nov 20 11:19:10 yes :) Nov 20 11:21:03 jow: I'm looking at adding persistent connections to opkg downloads, would it be acceptable to depend on libuclient/libustream-ssl? Nov 20 11:21:06 especially on the host Nov 20 11:24:11 speaking of tls client, this looks serious: https://bugs.openwrt.org/index.php?do=details&task_id=3465 Nov 20 11:24:14 "libustream-wolfssl20200215 doesn't validate TLS server certificates" Nov 20 11:27:07 * rsalvaterra thinks of replacing lzo and deflate with zstd, on ubifs… Nov 20 11:38:34 * karlp discovers he has wolf installed again, bah Nov 20 11:38:45 thanks zorun :) Nov 20 11:39:00 :D Nov 20 11:39:19 curl has openssl, and I have openssl for other things, but still ended up with libustream-wolfssl installed Nov 20 11:40:14 karlp: That was one of the reasons I made the {hostapd,wpad}-basic-openssl variants. ;) Nov 20 11:40:42 I'm stuck with OpenSSL for Tor… :P Nov 20 11:41:05 you still need wolf for wpa3 right? are we still in that trainwreck of compatibility? Nov 20 11:41:44 karlp: No. I have WPA3 Personal and OWE with hostapd-basic-openssl. Nov 20 11:41:56 I think the issue was with mbedtls Nov 20 11:42:03 Actually, I also wired up support for OWE in the -basic variants. Nov 20 11:42:31 remind me again why we have "Wireless" and "WirelessAPD" menus? Nov 20 11:42:58 the indentation of wpad is still all bogus though, that's never imrpoved :) Nov 20 11:43:12 wolf is still indended under openssl Nov 20 11:43:30 karlp: The indentation is… a mess, but I don't know how to untangle it, do I didn't. :P Nov 20 11:43:43 yeah, i tried once years ago, gave up very quickly .) Nov 20 11:43:43 *so Nov 20 11:55:05 [6~ Nov 20 11:55:23 I'm trying to find where in the source the filesystem for the overlay created (I believe it could be done at sysupgrade or first boot time). Does anyone know? :P Nov 20 11:55:34 *overlay is created Nov 20 11:57:47 karlp: i had to use the 'per device image' buildroot option to remove the wolfssl stuff and keep the openssl stuff Nov 20 11:58:10 at least, i think i had to. building for multiple devices in a single arch (mt7621, ath79) Nov 20 12:00:57 zorun: speaking of apu2's and pppoe, intel says i211at interfaces can do jumbo frames, i haven't figured out how to avoid 1492 byte mtu on the pppoe interface Nov 20 12:04:04 russell--: I never tried, but the other end also needs to support jumbo frames, it's not obvious it will work Nov 20 12:04:44 and by the other end I mean the whole network path that will transport your encapsulated packets... Nov 20 12:30:35 rsalvaterra: but does that {hostapd,wpad}-basic-openssl fit on 4m~ device? Nov 20 12:31:14 damex: Did you see the rationale behind it? Nov 20 12:31:39 rsalvaterra: wpa3 support for dumb ap? Nov 20 12:31:57 damex: No. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=10e73b1e9e35c3e86929a94d9b5c0d165b016df5 Nov 20 12:32:32 > this saves space by avoiding the need of an additional library (or a larger hostapd with built-in crypto). Nov 20 12:32:42 but does it fit on 4m now ?:) Nov 20 12:33:21 i wonder if it is time to find replacement for aircubes (ASAP!) or they could live till 'wifi6e' arrives Nov 20 12:33:30 s/aircubes/airgateways/ Nov 20 12:35:10 damex: No, it doesn't. WPA3 on 4 MiB devices will be difficult, if at all possible. Nov 20 12:37:22 https://github.com/openwrt/openwrt/pull/3037 would something like this be a decent choice? Nov 20 12:39:29 The AirGateway is an 8 MiB device. Nov 20 12:46:54 rsalvaterra: thanks, it is kinda slipped past me and i thought all the way that it is a 4MiB device ;p Nov 20 12:57:52 so technically should wpad-openssl on ar71xx device (19.07) be enough to get wpa3? Nov 20 13:08:54 damex: Do you need WPA Enterprise? Nov 20 13:09:04 rsalvaterra: nope, just 'personal' Nov 20 13:09:19 Ok, in that case, if you only need AP mode and you don't have anything that depends on OpenSSL, I'd recommend hostapd-basic-wolfssl. Nov 20 13:09:53 This will give you both WPA3 Personal and OWE. Nov 20 13:12:02 Is there a way to completely disable the kernel build? Including module packages, that's perfectly fine. I just want a rootfs to be used with externally built kernel. Nov 20 13:14:37 rsalvaterra: is it available for current release or have to built from scratch? can't see on mirrors/packages/device itself Nov 20 13:14:51 damex: Master only. Nov 20 13:15:08 oh, master have no support for ar71xx anymore :( Nov 20 13:15:14 Wait, no. Nov 20 13:15:18 I think… Nov 20 13:15:33 damex: Hasn't that device been ported to ath79? Nov 20 13:15:45 rsalvaterra: nope ;( Nov 20 13:20:05 make image PROFILE=ubnt-air-gateway-pro PACKAGES="wpad-openssl -wpad-basic luci" results in 4.9M so should be fine i guess Nov 20 13:20:27 in imagebuilder Nov 20 13:21:09 Yeah, should be fine. Nov 20 13:22:03 With your skills damex it shouldn't be too hard to port it to ath79 if there's nothing special about that device (mikrotiks being an example of special here) Nov 20 13:49:30 PaulFertser: yeah, should be straightforward to port. problem is that it is time consuming to recover device (tftp) since opening device casing for serial access - require sacrificing one of the devices (or most of it). so time it is Nov 20 13:50:34 technically board will be functional but casing will be in a very bad shape or not usable at'all. i find that it is completely glued. sometime even glued to the board Nov 20 13:51:09 I see. Unless you need it outdoors it's probably not that essential. Nov 20 13:53:30 damex: It's a ubnt device. Doesn't the bootloader contain a TFTP server? I recover my AirGrid easily that way. Nov 20 13:53:44 Never had to open it, and I've bricked it a couple of times. Nov 20 13:54:42 rsalvaterra: yeah, there is tftp recovery. it just takes time to do things semi-blindly that way :( Nov 20 13:55:58 Better than nothing, but I see your point… these devices are assembled once and not mean't to be opened again. Nov 20 13:56:23 *meant Nov 20 13:59:43 but we backported wpad-basic-wolfssl to 19.07 in case that helps you Nov 20 14:00:05 this should work with ar71xx unless you have a 4M device Nov 20 14:15:09 adrianschmutzler: Speaking of which, we really should treat hostapd and wpa_supplicant as separate daemons, even when building wpad… It doesn't make sense to start wpa_supplicant unconditionally, if the user hasn't configured at least one station (or hostapd, if the user hasn't configured at least one access point). Nov 20 14:15:55 rsalvaterra: That's not my realm, you will need to find somebody else to discuss that. Nov 20 14:16:01 I don't know how hard it would be, though. Splitting the init script is trivial. Nov 20 14:16:24 adrianschmutzler: Who'd you recommend? Nov 20 14:17:09 Maybe check out the git history of package/network/services/hostapd directory ... Nov 20 14:17:24 Ok, dangole, most likely. :) Nov 20 14:22:53 jow, reflashing 1907 from master, and keeping config (yes yes, not always a good idea) is giving me weird luci errors: /usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section 'main' Nov 20 14:23:07 but there is a main section there? Nov 20 14:25:57 this error is misleading, it might mean that rpcd is not started Nov 20 14:29:50 or any other issue in that path Nov 20 14:30:22 adrianschmutzler: rsalvaterra: thanks, i see that it works fine on 4 airgateways with wpad-openssl and it has enough free space. i will try to bundle all needed stuff along with wpad-basic-wolfssl later ;p Nov 20 14:33:59 so I might try wpa3 as well on R6220? Nov 20 14:36:07 mrkiko: I don't see why not. Nov 20 14:37:21 rsalvaterra: :D thanks. No no hardware assistance needed, all the changes are in authentication / hostapd Nov 20 15:44:08 rsalvaterra: we can hack logic into netifd to tell procd to start either or both instances only if configuration actually requires that. Nov 20 15:45:02 dangole: it would be really nice because currently it's just a waste of RAM for many people. Nov 20 15:46:32 rsalvaterra: if using 'wpad', the gains of doing so are minimal, just checked VmPTE: 16 kB, RssAnon: 104 kB for wpa_supplicant ideling on ath79/generic... (and that's all added in case hostapd applet of wpad is running from what i understand) Nov 20 15:49:11 rsalvaterra: but yet, you are right, not starting them on boot but letting netifd tell procd to start/stop them selectively if needed would be more elegant Nov 20 15:50:14 PaulFertser: The amount of RAM saved isn't as much as it seems at first sight. Since the code is only mapped once, it's shared by both instances. It's mostly a matter of efficiency, which I'm a bit obsessed with. :P Nov 20 15:51:28 rsalvaterra: on the other hand it's also nice to have them always available for performance reasons :) Nov 20 15:53:11 dangole: Compromises… ;) Nov 20 15:53:42 but - am I wrong, or when I do "wifi up" after changing config, they are killed and restarted? Nov 20 15:55:26 mrkiko: Hmm… I believe that changed recently and the configuration is updated without killing the processes, but I may be wrong. Nov 20 15:55:39 (On master, of course.) Nov 20 15:57:05 dangole is the hostapd guru, I'm just a n00b. :P Nov 20 15:57:33 rsalvaterra: it would be great!! Nov 20 15:57:34 BTW - was looking at Wi-Fi HaLow, wondering if I can find hardware supporting that. Nov 20 15:57:34 Seems nice Nov 20 15:58:59 mrkiko, rsalvaterra: currently dynamic reload is still optional. you have to do 'wifi reconf' to take full advantage of the new features. Nov 20 15:59:14 Ah, good to know! Nov 20 15:59:46 I guess there may still exist bugs to iron out. Nov 20 15:59:50 otherwise wireless_process_kill_all() is still called and kills the instance, which leads to somewhat similar to the pre-dynamic reload behavior. Nov 20 16:00:47 Yeah, wifi reload is *slow*. Nov 20 16:01:35 * rsalvaterra still hasn't found where the ubifs overlay partition is created/formatted… Nov 20 16:03:12 rsalvaterra: base-files/files/lib/upgrade/stage2 Nov 20 16:03:13 ?? Nov 20 16:03:16 just a guess Nov 20 16:04:11 Been there, but didn't see it… I was looking for a mkfs.ubifs call… Nov 20 16:04:45 I was expecintg something like ubimkvol Nov 20 16:04:55 The thing is, I see the kernel being built with lzo and deflate compression for ubifs, when zstd is already available, which doesn't make sense. If we're compressing, we should be using zstd. Nov 20 16:05:00 but I know nothing about ubi actually Nov 20 16:05:27 rsalvaterra: agree Nov 20 16:05:36 mrkiko: I know that ubi exists and what it is. I know that ubifs sits on top of ubi. Don't ask me anything else. :P Nov 20 16:05:48 rsalvaterra: at least in terms of performance / compression ratio. And I would love to be able to select SLOW but very compressive options Nov 20 16:06:30 Yeah, lzo is fast, deflate has good compression rato, but zstd is both fast and has good compression ratio. It's the best of both worlds. Nov 20 16:07:20 rsalvaterra: nand_upgrade_prepare_ubi() in nand.sh ?? Nov 20 16:07:58 mrkiko: Been there too, maybe I missed it…? Let's see… Nov 20 16:08:28 * mrkiko thinks one day he may benefit from looking well at the base-files package, lot of acumen here Nov 20 16:09:34 It looks like it, but I don't see any compression parameters… Nov 20 16:17:46 rsalvaterra: maybe we call it at build time and not in the device? include/image.mk Nov 20 16:18:40 rsalvaterra: around line 258 Nov 20 16:18:45 mrkiko, rsalvaterra: you are looking are the compression of ubifs-rootfs. not at the compression parameters of the ubifs overlay which you have on top of squashfs (which provides *much* better compression than ubifs at the cost of being read-only) Nov 20 16:18:57 mrkiko: I think that's for ubifs rootfs, not overlay… Nov 20 16:19:19 dangole: Right. Nov 20 16:19:25 rsalvaterra, dangole: sorry, you're right guys Nov 20 16:21:34 but now I'm curious :D Nov 20 16:23:51 we should enable CONFIG_UBIFS_FS_ZSTD by default imho Nov 20 16:25:13 dangole: And disable the others. *However*: mtd-utils needs to be linked against libzstd, I believe. Nov 20 16:26:45 (At least I tried to manually mkfs.ubifs --comp=zstd from our staging_dir, and it told me to sod off.) Nov 20 16:26:54 ok guys, but in nand.sh, around line 189 Nov 20 16:26:55 rsalvaterra: ...on host in order to generate zstd compressed ubifs rootfs images. for ubifs overlay i don't think anything is needed in userspace, all work done by the kernel, just give it the right mount options Nov 20 16:27:30 i can find only the mkvol call. Nov 20 16:28:13 dangole: If it's only for the rootfs case, perfect. But I still haven't found where the overlay ubifs volume is created, and with what compression options. :) Nov 20 16:28:29 you could even try something crazy like `mount /dev/ubiX_X /overlay -t ubifs -o remount,compr=zlib` Nov 20 16:30:00 I like that craziness. Nov 20 16:30:46 overlay is implicitely created by mounting the rootfs_data ubi volume. compression in per-file in ubifs, you can always decompress whatever your kernel supports and right now we just use the default (?) compression for newly written files as no mount option 'compr=...' is passed when procd mounts the overlay Nov 20 16:31:28 hence i was wondering if remounting could simply work to switch the compression used for files created of modified from then on Nov 20 16:33:14 dangole: In that case, the default is lzo, for sure. Nov 20 16:58:08 Aww… the MT7621 PCIe bus only supports a 128 byte payload size… :P Nov 20 16:59:16 … but the mt76 chips only support 128 bytes too. Fine, I guess. Nov 20 18:29:36 rsalvaterra: remount of overlay to change compression worked for me on my ubifs testing device: Nov 20 18:29:38 mount /dev/ubi0_1 /overlay/ -o remount,compr=zstd Nov 20 18:42:52 ynezz: ping Nov 20 18:42:56 dangole: rsalvaterra morning Nov 20 19:24:01 jow: at which point is `luci` or `luci-ssl` selected? It only happens on the buildbots right? Nov 20 20:05:26 anyone able to run openwrt on KVM for x86_64? what profile do you use? I have a C8 KVM server with cores to spare… Nov 20 20:05:55 yes, the x86_64 image runs just fine Nov 20 20:06:06 I haven't tested in a while though Nov 20 20:07:08 can you pastebin the .xml you’re using? Nov 20 20:07:40 I was having issues with the secure boot ROM stuff… Nov 20 20:08:05 zorun: do you still have the opkg size missmatch issue? I tried to fix it "upstream" to make packages reproducible, so ideally this patch wouldn't even be required Nov 20 20:10:04 you mean libvirt profile? I don't use libvirt Nov 20 20:10:37 aparcar[m]: it's still an issue in 19.07.4 yes, and it seems unfeasible to have 100% reproducible packages Nov 20 20:18:00 zorun: yes, libvirt/virsh… okay, how do you set it up? Nov 20 20:18:17 great this fixes a major annoyance with my upgrade server. I'll give it a try Nov 20 21:30:07 aparcar[m]: sup Nov 20 21:39:28 jow: Hi! Please can you apply your last fixes to uhttpd so they are available for the next 19.07 release? I've opened https://bugs.openwrt.org/index.php?do=details&task_id=3443 to track it. Thanks! Nov 20 21:46:52 zorun: "not obvious it will work" +1 Nov 20 22:11:40 SAn: done Nov 20 22:11:58 aparcar[m]: luci is selected by the buildbot seedconfig Nov 20 22:12:14 we never did a build with luci-ssl by default Nov 20 22:12:22 (which appears to be quite broken on master btw.) Nov 20 22:13:00 overall the ustream-wolfssl backend seems to be in a very deranged shape, certainly not stable release material Nov 20 22:13:05 jow: Great! Thank you! Nov 20 22:29:03 hm, switching to another ustream-ssl provider is also a huge hassle because it requires removing ustream-wolfssl which then breaks opkg due to the https requirement Nov 20 22:29:26 the certs generated by /etc/init.d/uhttpd are not readable by ustream-mbedtls either Nov 20 22:29:36 even which changing key type from ec to rsa Nov 20 22:30:05 that all feels very brittle and untested Nov 20 22:31:14 excellent, solid argumentation against having it in the next release ;P Nov 20 22:32:00 ustream-wolfssl in its current shape, is a desaster Nov 20 22:32:15 as reported in the bugs, it also fails to actually verify tls certificates Nov 20 22:32:19 I'm btw in favor to disable https per default again now that imagebuilders have signature checks Nov 20 22:32:37 so the stated goal of preventing MITM for package installs is missed Nov 20 22:32:47 therfore we can ditch https:// again Nov 20 22:33:09 please go ahead Nov 20 22:33:20 uhttpd is broken as well with ustream-wolfssl as backend, spurious http 400 errors. ustream-openssl and ustream-mbedtls work fine Nov 20 22:34:07 so we wait for mbedtls wpa3 support? Nov 20 22:34:40 or fix all the other wolfssl related regressions Nov 20 22:34:53 isn't wolfssl < mbedtls? Nov 20 22:35:09 no idea, I didn't follow the whole crypto craze Nov 20 22:36:34 at the very least - if we decide to release something with ustream-wolfssl by default - we should ensure that it verifies certiifcates as a minimum Nov 20 22:36:39 dangole: please join Nov 20 22:36:43 and that luci-ssl works Nov 20 22:37:03 or uhttpd w/ ssl rather, regardless of lucoi Nov 20 22:38:12 aparcar[m]: pong Nov 20 22:39:16 for 20.xx I'm against ssl support per default. While it first looked like we "just" need some LuCI UX we now have to fix actual crypto Nov 20 22:40:35 I agree. I'd rather ship without "crypto" than shipping broken crypto Nov 20 22:40:57 or just say, that we're aiming at 21.06 so there is plenty time to fix it Nov 20 22:41:32 would work for me as well Nov 20 22:42:28 but withouth skipping 20.xx please Nov 20 22:42:31 the main blocker here is dsa anyway Nov 20 22:44:02 the netifd side seems to be mostly settled Nov 20 22:44:20 defualt configs for dsa targets need to be adjusted yet and luci support merged and completed Nov 20 22:47:05 yeah, the luci part is probably essential for wider adoption and testing, then people will actually start using it, report corner cases aka release blockers and we've april behind the doors :) Nov 20 22:51:13 I can probably finish the LuCI DSA part until mid of december Nov 20 22:51:24 its 70-80% done Nov 20 22:51:52 only need to add wireless bridge-vlan support which is intentionally omitted atm because netifd didn't implement all required features until recently Nov 20 23:52:20 jow: so parts of it are already testable or nothing at all? Nov 20 23:52:24 (sorry been on lunch break) Nov 21 00:39:25 aparcar[m]: Good morning/afternoon! :) Nov 21 00:39:50 (I have no idea what time it is there. :P) Nov 21 00:45:27 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.5% packages reproducible in our current test framework.) Nov 21 00:50:49 dangole: Thanks! I'll try and build an image with only zstd enabled. Hopefully it will just work. Nov 21 00:52:43 rsalvaterra: what's your zstd plan? Nov 21 00:52:46 3pm here Nov 21 00:55:58 aparcar[m]: On ubifs systems, the supported compression is, at the moment, lzo and deflate, while zstd is also supported, but not selected. I believe we should switch to zstd, as it provides the best of both worlds (speed and compression ratio). Nov 21 00:59:33 And now, bed time. Cheers! :) Nov 21 00:59:40 rsalvaterra: okay bye Nov 21 00:59:54 I tried zstd for squashfs, maybe that's also something you want to look into **** ENDING LOGGING AT Sat Nov 21 02:59:56 2020