**** BEGIN LOGGING AT Tue Mar 31 02:59:57 2020 **** BEGIN LOGGING AT Tue Mar 31 03:07:53 2020 Mar 31 05:56:23 LoRez: yes, you can manipulate gpio pins by /sys/class/gpio interface, just echo N > export, then echo out > gpioN/direction; echo 1 > gpioN/value Mar 31 07:07:37 Hauke: "compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING" -> CONFIG_OPTIMIZE_INLINING=n for ath79 ? Mar 31 07:07:41 Hauke: good find BTW Mar 31 07:39:18 ot has been reported that https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.19/616-net_optimize_xfrm_calls.patch causes occasional null pointer derefs due to dev_net(skb->dev) being NULL Mar 31 07:39:31 I thought about fixing it but... Mar 31 07:39:52 1) why do we patch random return 0 statements into the core nat code? Mar 31 07:40:03 2) iss the claimed performance improvement worth the hassle Mar 31 07:40:21 3) has this change indeed been sent upstream? if not why is it in pending? Mar 31 07:40:56 I'd vote for dropping that patch Mar 31 07:58:25 :) Mar 31 07:59:30 indeed. This patch is more than 5 years old too Mar 31 07:59:33 I would love to have such stuff optional/experimental under some config option Mar 31 07:59:51 but thats easy to write then make it reality Mar 31 08:00:13 it probably breaks stuff in then unforeseen ways. Mar 31 08:01:04 https://github.com/openwrt/openwrt/pull/2039 next one Mar 31 08:01:25 from a cursory look at the kernel LXR, dev_net() cannot really result in NULL, at least none of the kernel users expects any NULL return value Mar 31 08:01:48 maybe the affected user has some local patches? Mar 31 08:08:23 maybe its an ipsec/xfrm speciality Mar 31 08:08:35 iirc the old ipsec stuff is "device less" Mar 31 08:08:46 maybe the dev_net() NULL is related to that Mar 31 08:09:06 but I am just talking out of my a** here, not an expert in kernel networking Mar 31 08:09:19 sent a patch to the ml, lets see if anyone objects Mar 31 08:31:05 ynezz: tmn505 did you read this comment? https://github.com/openwrt/openwrt/commit/2d61f8821c7cf99354e904139226c132554ba180#comments It's a bit misplaced I should have used bugs.o.o Mar 31 08:34:06 Basically the rename of CPU_SUBTYPE also changed the place opkg looks for packages which breaks package installation as the server uses a different path Mar 31 08:43:34 so now it needs to propagate on buildbots? Mar 31 08:44:21 because the default vfp3 is vfp3-d32, but those two targets need vfp3-d16 Mar 31 08:45:30 I don't know how this work on buildbot, `git grep vfpv3` doesn't yield anything under buildbot repo is it's automagic? Mar 31 08:45:53 s/is it's/so it's/ Mar 31 08:48:15 perhaps this is going to cause some hiccups during sysupgrade as well? Mar 31 08:49:48 or we should just put back `CPU_CFLAGS_vfpv3 = -mfpu=vfpv3-d16` which got removed in https://github.com/openwrt/openwrt/commit/8dcc1087602e2dd606e4f6e81a06aee62cfd4f4c ? Mar 31 08:49:52 is anyone working on 5.4 for ramips? Mar 31 08:50:11 russell--: AFAIK there is PR on github Mar 31 08:52:42 jow: do you know if the buildbots pick that up? Mar 31 08:52:44 ynezz: found it, thanks! Mar 31 09:10:29 russell--: what ramips devices do you have? Mar 31 09:10:51 my DIR-878 breaks but that's probably because i hacked the DTS :P Mar 31 09:11:01 haven't tested my RT-AC57U or DIR-860L B1 yet. Mar 31 09:24:17 jow: tmn505: aparcar: https://patchwork.ozlabs.org/patch/1264611/ ("mvebu, tegra: make CPU subtype default to vfp3-d16") makes more sense to me Mar 31 09:50:57 ynezz: nice rtt Mar 31 09:51:00 thank you Mar 31 09:52:51 the upgrade server turns out to be a good issue detector for snapshots https://github.com/aparcar/asu/issues/238#issuecomment-605923645 Mar 31 09:56:26 Borromini: a bunch, 7621, 7628, 7688, rt5350 Mar 31 09:59:46 mangix: is there a rule about using cmake somewhere? Mar 31 10:00:34 its not meson anymore? :p Mar 31 10:06:02 ldir: no. but it Mar 31 10:06:04 's better Mar 31 10:06:19 ynezz: cmake supports ninja Mar 31 10:06:47 i have a patchset in my tree that adds ninja to tools and uses it for cmake Mar 31 10:06:58 initial testing results are positive Mar 31 10:07:20 ninja feels blazingly fast Mar 31 10:09:33 mangix: link? Mar 31 10:10:21 hrm looks like I haven't pushed it yet Mar 31 10:10:56 I'll make a PR on github so people can test it. Mar 31 10:13:52 mangix: thanks Mar 31 10:15:11 so it looks like all I have to do is include $(INCLUDE_DIR)/cmake.mk CMAKE_INSTALL:=1 Mar 31 10:15:34 no Mar 31 10:15:41 actually... Mar 31 10:16:29 yeah that's correct Mar 31 10:16:44 CMAKE_INSTALL = PKG_INSTALL + InstallDev Mar 31 10:17:05 russell--: ok. curious about your experiences. Mar 31 10:17:11 allows elimination of the explicit InstallDev section Mar 31 10:18:01 ok thx, will try it Mar 31 10:18:34 ldir: make sure to check resulting pkgconfig files. some cmake packages generate bogus host paths Mar 31 10:18:56 i use grep libdir=/ *.pc to check for problems Mar 31 10:42:00 f00b4r0: so you have 802.11r working? what OS's on clients? Mar 31 10:42:48 i switched off ft_over_ds and still anything recent refuses to connect Mar 31 10:43:19 not even an attempt in hostapd's debug logs Mar 31 10:44:08 android 10+, iOS 13+, macOS 10.15+ all fail Mar 31 10:44:48 but any version below those connects Mar 31 11:04:45 DonkeyHotei: afaict ios works (I don't see the full RSN handshake when I roam) Mar 31 11:05:03 admittedly, I haven't turned off full hostapd debug output to confirm it actually does work :P Mar 31 11:05:21 DonkeyHotei: macos does not implement 802.11r afaik Mar 31 11:05:35 what version iOS? Mar 31 11:06:04 last one Mar 31 11:06:40 then you're doing something correctly that i am not Mar 31 11:07:26 or maybe I think it works and it really doesn't :) Mar 31 11:07:41 for you it connects, yes Mar 31 11:07:43 ? Mar 31 11:08:01 for me, it doesn't even try Mar 31 11:08:33 yes it connects Mar 31 11:09:19 in syslog on the APs the main difference I noticed is that for my iOS devices, I see "STA associated (aid N)" without the usual "WPA: pairwise key handshake completed (RSN)" Mar 31 11:09:32 whereas the other clients always complete RSN Mar 31 11:11:18 mind if i see your /etc/config/wireless? Mar 31 11:14:11 DonkeyHotei: https://pastebin.com/k98hek1y help yourself ;) Mar 31 11:14:17 (i removed the key, obviously) Mar 31 11:14:51 nasid is the AP's bssid without columns, as seems to be commonly recommended Mar 31 11:20:39 i see a couple of differences: Mar 31 11:21:11 1) you use upper case in the nasid, i don't (probably not important) Mar 31 11:21:42 2) you use psk2+ccmp, i use sae-mixed Mar 31 11:21:56 3) i also have the following lines: Mar 31 11:22:07 option ieee80211w '1' Mar 31 11:22:07 option wpa_disable_eapol_key_retries '1' Mar 31 11:28:11 also, you are doing it on 2.4GHz instead of 5, and you have require_mode 'n' Mar 31 11:33:40 ldir: I've added https://github.com/openwrt/openwrt/pull/1968 ("x86: add EFI images and make iso images EFI bootable") with some mods into my staging tree, would be nice if you could macbot build test it, eventually apu2 run test it :] Mar 31 11:35:06 DonkeyHotei: I never tried WPA3 (my aps are still running 18.06). Also, dunno if relevant since it's "old": Mar 31 11:35:06 https://wificoops.com/2019/07/28/wi-fi-security-enhancements-part-1-wpa3-personal-sae/ Mar 31 11:35:19 specifically: Mar 31 11:35:20 "Fast Transition (802.11r) needs to be disabled (802.11r support has been left out of the current versions of WPA3-Personal & WPA3-Enterprise). Roaming will use a PMKID roam for now." Mar 31 11:36:09 so 11r and sae are mutually exclusive? what is pmkid? Mar 31 11:36:09 another google hit shows: "Apple hardware generally supports FT very well (except with WPA3 Personal, for the curious)." Mar 31 11:36:21 i dunno. Google is your friend? :) Mar 31 11:36:44 I don't use wpa3. I don't need bleeding edge, I tend to favor stuff that Just Works™ instead ;) Mar 31 11:37:02 especially in the current conditions where internet is the true lifeline Mar 31 11:38:33 DonkeyHotei: https://support.apple.com/en-us/HT202628 answers your PMKID question at the bottom Mar 31 11:38:38 anyhow, lunch time Mar 31 11:38:51 ty Mar 31 12:11:10 Hauke: if you're around, commit 4a009a16d2e87da3cd0b994934d3c3b76ca0455b seems to fly in the face of the first quote above Mar 31 13:02:55 ldir: I've found the sd-card so tested it on apu2 myself as well Mar 31 13:04:33 aye src/ptgen.c:35:10: fatal error: 'linux/uuid.h' file not found Mar 31 13:14:47 ynezz: ptgen.c redefines GUID_INIT() anyway when it is not defined, so I think we can simply drop the linux/uuid.h include entirely Mar 31 13:14:58 nope Mar 31 13:15:15 ptgen.c:55:2: error: implicit declaration of function ‘UUID_LE’ Mar 31 13:15:18 tried that already Mar 31 13:15:55 ah right its supposed to be compat code Mar 31 13:16:12 I'd simply steal GUID_INIT() from here: https://github.com/torvalds/linux/blob/master/include/uapi/linux/uuid.h Mar 31 13:16:47 ptgen.c is GPL v2 as well Mar 31 13:51:59 jow: yep, looks good, thanks Mar 31 13:53:45 I'm falling over depends syntax. I'd like to do !@LINUX_4_14:+foo @LINUX_4_14:+bar Mar 31 13:56:38 is that possible ? Mar 31 13:57:35 ie select package FOO linux not 4_14, select BAR if linux is 4_14 Mar 31 14:00:33 wrong syntax? Mar 31 14:00:48 +@LINUX_4_14:foo Mar 31 14:01:06 +LINUX_4_14:foo Mar 31 14:01:19 +!LINUX_4_14:bar Mar 31 14:01:46 that last two without the @ Mar 31 14:02:32 if unsure, `git grep` is your friend :) Mar 31 14:09:09 ynezz: https://openwrt.org/docs/guide-developer/packages#dependency_types Mar 31 14:09:19 if this is still up-to-date: Mar 31 14:09:27 "Note that the + replaces the @" Mar 31 14:10:24 that would mean that there is no "+@". @ would be unselective, and "+" would be selective Mar 31 14:11:04 of course, that's just based from that wiki entry, and not verified at all Mar 31 14:13:03 too lazy to read the docs :) Mar 31 14:13:10 and grep seems to support that Mar 31 14:13:14 anyway, thanks for letting me know Mar 31 14:13:48 nice docs BTW Mar 31 14:13:59 actually, without that doc, I still wouldn't have understood that until today Mar 31 14:14:33 so I think !LINUX_4_14:foo LINUX_4_14:bar is enough? Mar 31 14:14:35 that "creating packages" seems to be widely unknown. I frequently get that feedback when I link it in PRs ... Mar 31 14:15:22 don't have history in irc though, so I don't know the background of the discussion Mar 31 14:15:37 (before I joined) Mar 31 14:16:45 ldir: +!LINUX_4_14:foo +LINUX_4_14:bar Mar 31 14:17:49 you can't probably mix both @+FOO:bar Mar 31 14:18:02 * ldir lol - tries again Mar 31 14:18:20 I'd be interested how that breaks; but I'm to lazy to try just for knowing ... Mar 31 14:18:38 it's `+foo` so `+BOO:foo` Mar 31 14:19:31 * ldir must be doing something wrong... has failed to generate any more recursive dependency warnings Mar 31 14:35:57 iirc @ is a special directive to refer to config symbols directly (any dependency word without an "@" prefix gets expanded to CONFIG_PACKAGE_$word) Mar 31 14:36:26 "+@" is technically possible but almost always unwanted since it introduces conditional compilation issues Mar 31 14:36:55 unwanted in public feeds or openwrt base package definitions that is Mar 31 14:37:17 it is fine for private use cases (e.g. for creating meta packages that enable kerne lfeatures or similar) Mar 31 14:38:42 jow: but is the difference only syntactically then, so +@a:b will do the very same as +a:b ? Mar 31 14:48:41 +@a:b is actually a syntax error since the entire part between "+" and ":b" is passed to kconfig as is Mar 31 14:49:06 +@a is valid however since it translates to "select CONFIG_a" in kconfig Mar 31 14:49:32 +@a:b would translate to "select CONFIG_b if @a" Mar 31 14:50:38 actually without CONFIG_ prefix Mar 31 14:51:00 +a:b => select b if a Mar 31 14:51:09 +@a:b => select b if @a [syntax error] Mar 31 14:51:17 +@a => select a Mar 31 14:51:22 +a => select PACKAGE_a Mar 31 14:53:43 and my first example was wrong too, +a:b => select PACKAGE_b if a Mar 31 14:54:14 not sure of +a:@b would work (select b if a) Mar 31 14:54:17 but it should Mar 31 14:56:01 so essentially "@" suppresses the implicit PACKAGE_ namespace prefix in the config variables and allowes to refer to arbitrary config symbols Mar 31 14:56:18 its just badly and inconsistently implemented Mar 31 14:56:39 leading to various quirks and counterintuitive syntactic behaviour Mar 31 14:57:59 ideally scripts/package-metadata.pl would implement a recursive parser that properly breaks down dependency expressions into an AST and then serializes it to boolean kconfig expressions Mar 31 14:58:39 right now it uses naive regexps and text interpolations which leads to overly complex (and faulty) select / depends expressions Mar 31 15:00:27 okay, thanks. I see. Should have a closer look at the code at some point ... Mar 31 15:43:50 ynezz: https://paste.ubuntu.com/p/gXCxZJpx8v/ Mar 31 15:44:38 needs some pie. I prefer cake, but I'll take a nice steak & ale pie if it's going :-) Mar 31 15:46:10 looks like perfectly normal linker behavior ;^P Mar 31 15:52:37 package/boot/grub2/Makefile - TARGET_CFLAGS := - hmmm. Mar 31 17:22:08 ynezz: kudos for taking care of the EFI patchset Mar 31 17:22:23 I guess with the recent churn on x86/64 it was the best time to merge it Mar 31 17:25:30 f00b4r0: DonkeyHotei I think this fixes the WAP3 problems with iPhones: https://git.openwrt.org/3034f8c3b85e70b1dd9b4cd5cd33e9d2cd8be3b8 Mar 31 17:25:34 it is in master and 19.07 Mar 31 17:30:15 Hauke: but ft-sae still has to be off, right? Mar 31 17:30:46 DonkeyHotei: I have never tried this Mar 31 17:31:23 the problem i am running into is not iphone-specific. it affects android the same Mar 31 17:33:18 the commit i referenced breaks all recent clients Mar 31 17:35:46 Hauke: can you double-check the wpa3 spec with regard to ft-sae? Mar 31 17:37:39 Hauke: DonkeyHotei: My testing shows that enabling FT-SAE makes my Pixel 3 unable to connect. Mar 31 17:38:08 ^this Mar 31 17:38:32 anything android 10+ Mar 31 17:38:45 (And when that happens, absolutely nothing is logged by the WAP, regardless of loglevel.) Mar 31 17:38:54 yep Mar 31 17:39:15 same with ios 13+ and macos 10.15+ Mar 31 17:55:23 DonkeyHotei: curently I am not using FT-SAE Mar 31 18:25:28 Hauke: i think it's highly likely that commit specifies ft-sae incorrectly Mar 31 18:43:23 I can't persuade jansson to build using cmake - it seems determined to use autotools to configure - I can't work out why Mar 31 18:54:22 yet another nand driver for mt7621: https://patchwork.ozlabs.org/patch/1264889/ Mar 31 18:55:44 but it's immediately rejected within an hour - The author was told to refactor existing mtk_nand driver. Mar 31 18:57:18 I'd still like to use this driver for the ramips 5.4 pr though. At least it's using latest nand APIs in kernel. Mar 31 19:05:09 DonkeyHotei: Which commit is that? Mar 31 19:05:48 4a009a16d2e87da3cd0b994934d3c3b76ca0455b Mar 31 19:06:36 Thanks! Mar 31 19:14:12 mamarley: let me know anything new on that Mar 31 19:15:06 According to the hostapd documentation, the "FT-SAE" thing does appear to be correct, but I'm not particularly knowledgeable about this stuff, so I may be missing something. Mar 31 19:35:19 mamarley: the link pasted earlier suggests that violates the wpa3 spec Mar 31 19:37:04 Interesting, I had never read that before. I wonder why "FT-SAE" exists at all then· Mar 31 19:58:01 mamarley: that's what i'd like to know Mar 31 20:12:30 any reason not to shore the used profile on the build images? Mar 31 20:13:11 board_name doesn't match the used profile, so it is extremly hard to recreate the image running on a specific device Mar 31 20:13:17 (for a machine) Mar 31 20:13:29 or I'm missing some obvious way to figure it out Mar 31 21:35:24 PaulFertser: it looks like there are three CS lines provided by the ar7161. one that's "normal", then two more that are multiplexed GPIO 0 & 1. (according to the datasheet) That doesn't account for the 4th line though. Mar 31 21:37:32 LoRez: do you have their uboot sources? Mar 31 21:37:50 no. Mar 31 21:38:24 Can you get it? Mar 31 21:39:25 I could ask? isn't the license one that doesn't require redistribution of changes? Mar 31 21:39:51 LoRez: if it's uboot then it's GPL so they must provide all the sources Mar 31 21:40:03 O_o Mar 31 21:40:28 that.... should've occured to me before. Mar 31 21:44:02 gch981213: I am fine with you use this rejected driver Mar 31 21:44:20 I hope they will send a better patch in the next weeks and then we can switch to the upstream version Mar 31 22:36:45 DonkeyHotei: i would try with plain hostapd and maybe a packet sniffer to see, what is going over the air. Mar 31 22:37:51 My experience with WPA3-personal / WPA3-Enterprise as well as OWE was "interesting" at best on all platforms. Mar 31 22:38:11 i tried disabling sae, still no go Mar 31 23:39:59 blocktrron: it seems if i enable _either_ 802.11r _or_ 802.11w _without_ sae, android 10 cannot connect Mar 31 23:40:29 on 19.07 Apr 01 00:09:30 DonkeyHotei: what device are you using? Apr 01 00:10:19 I'm using SAE+802.11w as well as WPA2+802.11w withot issues (Android 10 - Nokia 6.1) Apr 01 00:10:39 Same goes for someone with a Pixel 3a Apr 01 00:11:04 Which router are you using? Apr 01 00:11:50 Hi I now have 1582 tweets about this and I think it would for some one from openwrt to make some Comments. Apr 01 00:11:56 compex card on x86 Apr 01 00:11:56 https://arstechnica.com/information-technology/2020/03/openwrt-is-vulnerable-to-attacks-that-execute-malicious-code/?comments=1&post=38769145 Apr 01 00:12:23 9884 Apr 01 00:15:07 on 5GHz Apr 01 00:19:51 DonkeyHotei: have you tried with QCA firmware and driver instead of the ct ones? Apr 01 00:20:06 not recently Apr 01 00:21:16 Well, my experiences are based on 19.07 + QCA9888 / IPQ4019 + qca-firmware/driver. Apr 01 00:21:36 no attempts with -ct? Apr 01 00:21:37 I have a r7800 at hand, so i can have a look if you want Apr 01 00:22:41 Tapper: I've read the article but I'm not sure what's meant with a long-term fix when 19.07.2 is out Apr 01 00:22:51 it might be interesting to compare qca vs. ct vs. ct-htt Apr 01 00:23:26 We are using non-ct exclusively to be consistent with Wave1 cards (-ct does not support 802.11s) Apr 01 00:24:30 the other device i could roam to is wave1 Apr 01 00:24:37 archer c7 v2 Apr 01 00:25:11 but i turned off its 5ghz for the test Apr 01 00:25:47 mips kernel config needs to be fixed Apr 01 00:25:48 MIPS32 Release 3.5 Features (CPU_MIPS32_3_5_FEATURES) [N/y/?] (NEW) Apr 01 00:25:49 MIPS32 Release 5 Features (CPU_MIPS32_R5_FEATURES) [N/y/?] (NEW) Apr 01 00:30:25 malta is totally broken Apr 01 00:30:25 sight Apr 01 00:30:28 *sigh Apr 01 01:00:43 Hauke: That won't happen. I've asked the author about this driver: he wrote this driver because he's bored last weekend. He has no interest to voluntarily rewrite mtk_nand which isn't maintained by him. Apr 01 01:02:38 what is triggering /etc/rc.button/reboot ? Apr 01 01:07:28 russell--: procd Apr 01 01:09:15 aha! a46259787d0 package/kernel/button-hotplug/src/button-hotplug.c (Alan Swanson 2019-05-29 11:36:12 +0100 88) BH_MAP(KEY_POWER2, "reboot"), Apr 01 01:09:48 i was using KEY_POWER2 for something, wondered why my board kept rebooting! ;-) Apr 01 01:13:11 "improbability" indeed, /me steals a space ship and designs some fjords Apr 01 01:57:37 Hi blocktrron There is a dude in the comments pointing out bits of code saying there is a bug, but I don't know how to respond. Apr 01 02:51:43 Tapper: what about 'nothing'? talk is cheap, but unless anyone actually provides a patch or at least reports a detailed bugreport, there really isn't a whole lot to discuss about (and even less indirectly through middle-men) **** ENDING LOGGING AT Wed Apr 01 02:59:57 2020