**** BEGIN LOGGING AT Wed May 12 02:59:56 2021 May 12 07:11:35 hrrm, FragAttacks.com published now... May 12 07:11:53 Raises question what OpenWRT state, statement/response is! May 12 08:34:17 enyc: These vulnerabilities exist at the kernel and firmware level. When (if, depending on the hardware) they're fixed upstream, the patches will be backported to stable kernels. It's business as usual. May 12 08:37:53 rsalvaterra: hrrm, is this why there are things like candelatech modified atheros firmwares and so-on ? May 12 08:38:11 rsalvaterra: [upstream wifi chip vendor not supporting fw] etc... May 12 08:40:14 I had to switch back to ath10k because the -ct version just crashes randomly and upstream says they can't fix it. May 12 08:40:26 enyc: In case of ath10k, it started with fixing vendor firmware bugs and including features it didn't implement. May 12 08:40:48 Q_: What ath10k hardware are you using? May 12 08:42:23 rsalvaterra: ping May 12 08:42:39 Grommish: pong May 12 08:42:50 QCA9880 / QCA9560 May 12 08:43:35 rsalvaterra: Would you know how to add .ko deps to a kmod_ package? I've got a kmod_nf_nat that needs 2 .ko files that aren't being copied May 12 08:43:47 the kmod package is confusing and scary :D May 12 08:44:16 Q_: For QCA9880, you need the -ct firmware if you want WPA3 support without fatal firmware crashes. The crashes will still happen, but the -ct firmware is able to recover. May 12 08:45:12 Grommish: Sure, I've done it before. Do you know the exact dependencies? May 12 08:45:27 rsalvaterra: I do.. https://forum.openwrt.org/t/adding-ko-files-to-kmod-package-dependancies/96373 May 12 08:46:49 That's not OpenWrt… :P May 12 08:46:56 Now, now ;p May 12 08:47:21 I'm doing a POC build to ensure the drivers are all kernel based May 12 08:47:30 before I go ripping them out and putting them into 5.10 May 12 08:48:02 I tried a 19.07 build, but it just stopped at the Booting Kernel stage.. so, I'm trying main branch again May 12 08:48:33 Grommish: Ripping them out… as in the source code, right? Not the compiled modules. May 12 08:48:39 Right May 12 08:48:39 It works without problems with the non-ct version. I've not checked that WPA3 works properly, it might not have any devices that connect to it using WPA3. May 12 08:49:17 rsalvaterra: I know better than that :) But, I also have the full ralink source in the kernel gpl.. and all kinds of tasty configuration options now with a proper dts and whatnot May 12 08:50:56 Q_: I failed to mention that the problem is also present for WPA2 with MFP (802.11w). MFP is the culprit (and it's mandatory in WPA3). May 12 08:51:20 rsalvaterra: HW IPSec and HW Nat enabled. The HW Crypto engines, etc May 12 08:51:36 Grommish: That's mighty sweet…! May 12 08:51:59 rsalvaterra: If I can get it to build.. but, I keep learnnig new things and hitting new walls..this is the latest :) May 12 08:52:27 That kmod libs have to do with the hw nat, so I need to add them to the kmod file May 12 08:54:21 rsalvaterra: https://gist.github.com/Grommish/49263bbe65c405f5f2e0f032e6de29c1 May 12 08:55:27 Grommish: Hm… That hwnat implementation is probably too ad-hoc to be merged upstream. It needs to be a hardware flow offloading implementation on a DSA switch, like we have on MT7621, for sure… May 12 08:55:52 One thing at a time.. Once I get it working, I've got the technical sheets for the RTL8367RB May 12 08:56:03 Although this is a legit driver for that board May 12 08:56:29 Symbol: NET_REALTEK_RTL8367_PLUGIN [=y] May 12 08:57:12 DSA can come later ;p May 12 08:57:23 rsalvaterra: My laptop that's configured to only do wpa3 is happy to connect to it. May 12 09:00:19 Q_: That's rather strange. Running Linux? May 12 09:01:07 Yes May 12 09:11:26 Q_: can you check 21.02RC builds with ath10k firmawer inrluded? I think this may need to be sorted/bugreported/etc for 21.02 release.... May 12 09:11:41 Q_: I need to attach more serial consoles (may be able to at weekend/monday) to monitor mine May 12 09:17:28 f00b4r0: patch pushed to master and backported to 21.02. Thanks for looking into that so fast May 12 09:22:36 It runs a 21.02 snapshot (r15831-c74df745fd), but I can try a newer one if you want. May 12 09:24:24 Q_: i'm not expert but basically I also suspect ath10k-ct firmware issups and I think issue/bug needs to be created for 21.02 May 12 09:24:48 may be better 21.02 released with non-ct firmware as it appears crash issues happen etc May 12 09:30:14 enyc: I have a bug report here: https://github.com/greearb/ath10k-ct/issues/178 May 12 09:31:56 Q_: ok i'll tryi to keep that open for when i can collate some moredebug May 12 09:32:11 Q_: in any case, openwrt bug ref, how this to be sorted for 21.02 ? May 12 09:39:35 xback: np yw May 12 10:23:55 jow: do you think that board.json should also have layer 2 and layer 3 separated? May 12 10:24:24 to avoid mixing them like: May 12 10:24:25 "lan": { "ifname": "lan1 lan2 lan5 lan6 sw", May 12 10:24:27 "protocol": "static" } May 12 11:04:42 aparcar[m]: sounds good May 12 11:05:01 jow: ty May 12 11:05:04 rmilecki: eventually yes May 12 11:05:36 jow: while I got your attention: https://github.com/openwrt/luci/pull/5041#issuecomment-839646364 May 12 11:10:23 aparcar[m]: too much text to quickly scan through, do you want me to ask something specific? May 12 11:10:42 jow: please design a generic notification system :) May 12 11:10:54 yes notifications are fine, notification framework... probably makes sense May 12 11:12:04 the thing feckert came up looks like a good start May 12 11:13:21 instead of the modal popup, you could call http://openwrt.github.io/luci/jsapi/LuCI.ui.html#addNotification for each notification read from ubus May 12 11:13:41 it allows for arbitrary markup May 12 11:13:55 and should display a yellowish banner at the top of the view May 12 11:13:58 but it blocks from further input May 12 11:13:59 may be called multiple times May 12 11:14:08 no, it shouldn't May 12 11:15:09 on a random luci page, open the browser debug console and enter `L.ui.addNotification('Example', '

foo

')` May 12 11:16:45 should look like this: https://paste.pics/647f880ab8f038a45ae90ab23d7ffad3 May 12 11:17:12 you just need to figure out a way to let the "Dismiss" button also delete the notifaction May 12 11:17:55 either by attaching an event handler after the fact (ui.addNotificatio() returns the div node of the banner) or by changing ui.addNotification() itself to allow more control over the rendered contents May 12 11:24:18 Perfect. I confused it with this modal thing which takes over the screen May 12 11:42:46 that service() function thing which was added a while back is really weird May 12 11:43:00 service help -> listing May 12 11:43:04 service foo -> listing May 12 11:43:08 service list -> listing May 12 11:43:15 service dnsmasq -> help May 12 12:15:02 jow: looks like only a "help" function is really missing May 12 12:15:37 if service exists: show possible options, if not, show available services (with status) May 12 13:27:52 rmilecki: ping May 12 13:30:18 nbd: pong May 12 13:31:27 i've taken a quick look at your patch regarding 'config bridge' support May 12 13:32:14 first of all, i think it would be a good idea to simply rename the 'ports' option to 'ifname' in config_init_bridges May 12 13:32:32 in order to avoid processing two potentially conflicting options for the same thing on config device/interface sections May 12 13:32:48 with rename, i mean using uci_rename May 12 13:32:56 so sticking to your syntax in actual config files May 12 13:33:22 and then there's another thing: May 12 13:34:15 since you wanted to have bridges that are brought up by default, i think the new config syntax is a good opportunity to do so without potentially adding regressions to old configurations May 12 13:34:29 nbd: sounds good May 12 13:34:36 nbd: any hint how to handle that? May 12 13:34:38 how about having a 'config bridge' section imply the creation of an implicit proto=none interface with the same name May 12 13:35:00 that would allow you to use ifup/ifdown on the bridge as well May 12 13:35:15 oh, that magic creation of interfaces worries me May 12 13:35:18 more magic I mean May 12 13:35:22 jow: ^^ May 12 13:35:40 nbd: could bridge.c code simply create bridge on device_create() callback? May 12 13:35:53 nbd: why do we need actual event to create bridge? May 12 13:36:53 14:34 < nbd> how about having a 'config bridge' section imply the creation of an implicit proto=none interface with the same name May 12 13:36:56 please no! May 12 13:37:00 more magic implicit state May 12 13:38:16 i mean right now, you can use ifup/ifdown to recreate the state of dynamically created interfaces like vlans, bridges, etc. May 12 13:38:41 creating bridge devices without any interface user breaks that May 12 13:38:58 or we would need to add a separate devup/devdown, or parameters to ifup May 12 13:39:20 but then we have a lot of potential for bad interactions with device refcounting May 12 13:39:38 and the internal data model of netifd starts getting more messy than it already is May 12 13:46:54 so while in principle i agree with having less magic, the implicitly created interface is the least intrusive and least problematic way of implementing this feature that i can think of May 12 13:47:13 and it's easier to handle from CLI if you can just use regular ifup/ifdown on it May 12 13:48:42 if you guys can think of a better way, please let mek now May 12 13:59:26 jow: this is a bit too complex for me at this point, let me (us) know if you know how it could be handled May 12 13:59:59 for now i'm voting for 1. no magic interface 2. having to create UCI interface config even if its dummy May 12 14:13:49 rmilecki: in that case, i don't know if it's such a good idea to merge the patch that adds the 'config bridge' support May 12 14:14:15 because then it simply introduces yet another way to configure the exact same thing, except for one renamed config option May 12 14:14:33 nbd: let me quickly share my long term plan May 12 14:14:43 nbd: i want new UCI section syntax (type actually) May 12 14:15:00 then I want to translate old syntax to the new one May 12 14:15:04 then drop old syntax support May 12 14:15:11 that applies to bridge as well as other types May 12 14:15:17 jow: ^^ May 12 14:16:19 i think any change that leads to eventually breaking old configs should come with some significant benefits May 12 14:17:04 otherwise you're simply adding lots of migration churn, ui changes, etc. May 12 14:18:18 i believe it's going to result in cleaner UCI and LuCI in the final form May 12 14:18:57 then maybe we should hold off on these sorts of changes until we have a draft for the final form May 12 14:19:00 and migrate to that May 12 14:19:41 nbd: I can document that first if it helps, sure May 12 14:20:04 that would be helpful May 12 14:20:10 will do May 12 14:20:16 because the ifname->ports change alone is not enough to justify it, in my opinion May 12 14:20:48 and if you support a half-baked new syntax, and people start using that before we've even implemented the full new syntax, we have even more extra churn and nasty surprises for users May 12 14:21:54 Build [#44](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/16/builds/44) of `realtek/generic` failed. May 12 14:44:09 libgpg-error doesn't build for me: https://gist.github.com/b845c7e079b009d53da213b5a056d606 - reverting the bump to 1.42 fixes that but according to the checks in the PR it built fine ... anyone any idea ? May 12 15:16:19 Build [#88](https://buildbot.openwrt.org/master/images/#builders/64/builds/88) of `realtek/generic` failed. May 12 17:08:10 nbd: thanks for taking care of that fartattack fixes! May 12 17:08:33 yw May 12 17:08:41 seems like we should prepare release as well May 12 17:09:15 ynezz: fart you say? May 12 17:09:17 19.07.8 and 21.02.0-rc2 May 12 17:09:23 ;) May 12 17:09:38 ah, typo, sorry May 12 17:10:44 Hauke: zorun: ^ May 12 17:19:01 ynezz: i plan on adding mt76 fixes some time this week May 12 17:19:17 19.07 probably doesn't need an mt76 fix May 12 17:20:01 the mt76 issue only affects 7615+ with a-msdu and 802.3 decap offload (which isn't in 19.07) May 12 17:41:30 does busybox intentionally lacks the build date? May 12 17:41:42 BusyBox v1.33.0 () built-in shell (ash) May 12 17:41:55 it should usually be within the brackets May 12 17:44:23 likely a consequence of reproducible builds May 12 18:03:10 I'll look into that, would be cool to add in the last git source or something May 12 18:03:27 this seems like an awkward thing https://github.com/openwrt/openwrt/pull/4167 May 12 18:06:22 lynxis: looks like you did 34df4d40e20, comments? May 12 18:06:39 the kernel already uses EPOCH afaik May 12 18:10:32 aparcar[m]: changing the busybox dns resolving preference just like that is asking for trouble May 12 18:10:45 I'd strongly advise against it May 12 18:10:57 broken ipv6 is far more common than one might expect May 12 18:11:39 ideally I'd use happy eyeballs for its primitive resolver functions May 12 18:11:45 s/I'd/it'd/ May 12 18:12:20 sorry, that was bs, not for resolving, but for connecting() and stuff like that May 12 18:13:31 in general this looks like a case of PR activism to me May 12 18:14:13 "mhh... my OpenWrt is having 4 NTP peers instead of just one"... "hmm ntpd behaves weird"... "hmm busybox sucks"... "Change all the things!!!!" May 12 18:14:59 proposing to change the resolve preference without any sort of information about conducted tests, possible regressions etc. is an absolute no-go" May 12 18:15:07 jow: well you know me, I'm not looking for trouble May 12 18:16:33 s/not // :D May 12 18:16:40 all right I just looked at the sources and it seemed like a trivial issue fixed by that, see https://bugs.busybox.net/show_bug.cgi?id=12381 May 12 18:17:09 ;) May 12 18:19:19 I updated my comment to not encourage anyone to much May 12 18:25:20 aparcar[m]: I am too dense to understand that busybox bug report you linked May 12 18:25:37 ah nevermind, got it May 12 18:26:10 so what this features does is pulling ipv4 replies first to return if there's any May 12 18:26:17 instead of simply using the first resolver reply May 12 18:26:22 fine with me then May 12 18:26:36 I thought this option somehow changes the way DNS queries are made May 12 18:27:00 aparcar[m]: what's wrong with 34df4d40e20? May 12 18:31:39 ynezz: yes we should do a 19.07.8 and 21.02.0-rc2 soon May 12 18:34:45 lynxis: i want the (reproducible) build date in the BusyBox line May 12 18:35:30 Hauke: please wait until we have the SRV thing backported or people will be sad May 12 18:36:15 jow: I'll try to get some ipv6 and give it a try May 12 18:40:41 aparcar[m]: if it's possible by now to build busybox reproducible with a date go for it. I would love to review it. May 12 18:48:42 lynxis: I'll have to cook come potatoes but I'll keep you posted later tonight. We share the same TZ btw May 12 18:49:12 aparcar[m]: are you back again or just on a short visit? May 12 18:49:18 aparcar[m]: I'm unsure if you're in the us or in germany :) May 12 18:50:32 lynxis: ger May 12 18:50:37 Hauke: visit May 12 18:56:01 It's question if ath9k needs to be updated as well. Maybe it would require to update firmwares as well May 12 18:58:02 I'm facing a lot of DFS events on my (old) ath9k devices. e.g. wdr4300 on channel 60. It can't be an official weather radar. May 12 20:23:34 microwave ? May 12 20:34:41 blogic: ping May 12 20:35:15 yo May 12 20:35:25 concerning the uci poe discussion May 12 20:35:31 yeah May 12 20:35:49 I've ported two devices already that a simple, GPIO-enabled PoE passthrough May 12 20:36:05 I think these could also be supported by the uci PoE config May 12 20:36:05 ok, got a git link ? May 12 20:36:25 which devices are these ? May 12 20:37:04 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c9f51a9ad6e8f99ed7adb78d208740b7d351985b May 12 20:37:16 https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1e75909a35a2b361cdfdfcf18a26ad61271b174e May 12 20:37:40 currently I've exported those GPIOs through gpio-export May 12 20:37:51 ok May 12 20:37:54 but I just realised these could fit in the regulator framework May 12 20:38:02 https://mjmwired.net/kernel/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml May 12 20:38:02 yeah May 12 20:38:24 that was exactly what I was thinking May 12 20:38:41 Borromini has an EAP235-Wall, I'm sure he'd be glad to test any proposed solutions :) May 12 20:39:29 well, he is an usual suspect so I would expect a 'yes' May 12 20:39:40 ;) May 12 20:39:59 ok, I'll cook up a patch to export a fixed-regulator with that GPIO, and ask if he has time to test :-) May 12 20:40:16 cool May 12 20:40:36 then that would provide a second type of "PoE controller" you can use to cook up a uci-syntax May 12 20:40:49 once that is ready I will adapt it for the ubnt er-x* units May 12 20:40:59 yeah May 12 20:41:36 it wil take a bit of desing considoration to find a generic approach May 12 21:03:48 ping greearb ? May 12 22:23:19 Ansuel: just as a quick update, root@nbg6817:~# uptime --> up 20:57, all fine with your current dsa PR - now preparing a new build including tsense/ PCI I/O changes ;) May 12 22:45:28 pkgadd: nice! any difference with speed and cpu load? May 12 22:51:31 Ansuel: my 'feeling' suggests that it might be a little slower (~365 MBit/s vs 420-430 MBit/s), but hard to say for sure May 12 22:53:36 pkgadd: you mean with the old patch or with swconfig ? May 12 22:54:50 right now I'm referrring to the old dsa patch, but swconfig in general might have been a little faster (slightly less CPU intense) overall, it's hard to say for sure May 12 22:55:50 I'm not far away from the ceiling ipq8065 can do without NSS - and reliable speedtests are also hard to get at 400/200 MBit/s ftth May 12 22:56:24 so the results may vary unrelated to the router as well May 12 22:59:26 dslreports: 364.7/201.4, fast.com: 400/200, waveform.com: 362.7/ 207.0, speedtest.net: 398.11/ 205.41, breitbandmessung.de: 392.42/ 216.32. I'm usually seeing ~422-430/ 211 MBit/s. May 12 23:00:55 what i notice from the swconfig driver is that the dsa driver massively pool the mdio interface to get the port status while swconfig didn't use that at all... think this is what slow down the driver... May 12 23:02:24 iirc that has been an issue with swconfig before, so the polling was tuned down May 12 23:03:03 as qca8337 is slow to report those stats May 12 23:05:37 Ansuel: iirc related to https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6648e9458f2f47cdbe16bd9537f08048a0a252fd May 12 23:06:42 and https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=107dc4326ccfaff27bd1e698b8bc7fb942233559 May 12 23:08:00 i need to check if something like that is present for dsa... May 12 23:41:26 Could we get irqbalance included and enabled by default for the R7800 and other multicore routers? May 12 23:41:42 Why is this a manual, extra step on these? May 12 23:43:13 Is there a good reason this is not included and started by default generally? **** ENDING LOGGING AT Thu May 13 02:59:56 2021