**** BEGIN LOGGING AT Mon Aug 06 03:00:00 2018 Aug 06 03:59:45 morning Aug 06 04:01:23 mangix: did you have time to test that roaming wifi exploit thing ? Aug 06 04:01:33 mangix: and is there a linux mitigation patch for it ? Aug 06 04:04:24 DonkeyHotei: https://github.com/openwrt/openwrt/pull/1238 Aug 06 04:04:29 DonkeyHotei: does this fix your issue ? Aug 06 04:09:32 blogic: that is a separate problem, and there is a regression potential in that pr if a dts has bad copypasta Aug 06 04:10:01 instead, the problem is here: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mdio.c#L113 Aug 06 04:10:31 comes from this commit: https://dev.archive.openwrt.org/changeset/43108 Aug 06 04:10:48 dont tell me where to look and guess Aug 06 04:10:50 tell me the problem Aug 06 04:11:29 that line disables gigabit support categorically when phy_init is used Aug 06 04:11:38 ok Aug 06 04:11:50 lets fix it then Aug 06 04:12:00 i am building a e1700 image just now Aug 06 04:12:09 and how is that other thing a regression ? looks legit Aug 06 04:12:10 i've staged a patch but i was gonna ask about that line before making a pr Aug 06 04:12:31 show me your commit please Aug 06 04:13:31 last 3 here: https://github.com/danielg4/openwrt/commits/master Aug 06 04:14:59 DonkeyHotei: i'll take all 3 Aug 06 04:15:05 send a PR please Aug 06 04:15:23 and with the "confusion fix" that other patch should not cause a regression afaict Aug 06 04:16:15 i was also awaiting a final test from someone who actually has the edimax device before doing the pr, but the e1700 should be tested with and without the last commit Aug 06 04:16:28 yep Aug 06 04:16:43 send a PR please so i can build an image with the patch applied Aug 06 04:17:32 at least a test without it will show whether the e1700 is pegged to 10/100 Aug 06 04:17:51 if so, the fix should go to the 18.06 branch too Aug 06 04:18:02 but not the other 2 commits Aug 06 04:19:17 yes Aug 06 04:24:42 pr 1238 will need an adjustment to avoid regressions, but the "confusion fix" would be a prerequisite Aug 06 04:25:33 change "} else {" to "} else if (!mdio_mode) {" Aug 06 04:42:24 ok Aug 06 04:43:22 philipp64: "opkg install perl-device-serialport" on 18.06.0 installs it into /usr/lib/perl5/5.26, but perl is 5.28, so it doesn't find it Aug 06 04:44:30 ditto with all the other non-perlbase pkgs Aug 06 04:50:28 DonkeyHotei: its pegged at 100 Aug 06 04:50:33 can you send the PR please ? Aug 06 04:50:44 i'd like to merge it now and then move onto the next board Aug 06 05:04:42 sent Aug 06 05:05:59 but i'd rather it be at least tested on the e1700 Aug 06 05:10:14 confirmed working Aug 06 05:10:21 lets pull that 4th patch and test it aswell Aug 06 05:15:39 i strongly recommend changing the else to else if in pr 1238 Aug 06 05:17:04 as for the commit adding the edimax board, the dts mixes "#include" with "/include/" which is a bit ugly Aug 06 05:17:24 forgot to fix that Aug 06 05:17:32 DonkeyHotei: Sounds like they all need to be rebuilt. Aug 06 05:17:48 philipp64: yep Aug 06 05:18:03 odd that they don't depend on lang/perl/Makefile … Aug 06 05:19:10 btw, symlinking 5.26 to 5.28 yields: Aug 06 05:19:12 SerialPort.c: loadable library and perl binaries are mismatched (got handshake key 0x8b00080, needed 0x8300080) Aug 06 05:19:33 yeah, that's never worked. Aug 06 05:34:39 f00b4r0: what is RTF ? Aug 06 05:37:55 build #27 of mediatek/mt7622 is complete: Failure [failed kmods] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mediatek%2Fmt7622/builds/27 blamelist: Stijn Segers Aug 06 06:32:26 commit 379fe50 wasn't cherry-picked into 18.06... Aug 06 06:38:34 for that matter, f6d81e2 should also be Aug 06 07:12:01 build #84 of mvebu/cortexa72 is complete: Failure [failed kmods] Build details are at http://release-builds.openwrt.org/18.06/images/builders/mvebu%2Fcortexa72/builds/84 blamelist: Stijn Segers Aug 06 07:13:52 DonkeyHotei: yep on it, got side tracked by kid waking up Aug 06 07:14:03 also mkresin complained that y6our patch smells like poo poo Aug 06 07:14:08 so i'll fix that aswell in a sec Aug 06 07:14:32 morning Aug 06 07:14:38 wigyori: hi there Aug 06 07:14:41 yoo Aug 06 07:18:57 which one? Aug 06 07:19:26 hi guys Aug 06 07:19:43 so i made the blamelist huh :( Aug 06 07:20:50 where ? Aug 06 07:21:07 blogic: the buildbot ^^ Aug 06 07:21:15 ah ok, i just pushed a fix Aug 06 07:21:30 ok so it's not my fault? :P Aug 06 07:21:48 we had the same issue in trunk Aug 06 07:21:53 oh. Aug 06 07:21:54 there is a new aarch64 symbol Aug 06 07:22:49 git has been loading slowly for a few days now, don't know if someone else noticed Aug 06 07:24:09 blogic: i should have known, sorry. koen told me to add that SSBD symbol, which I did for 4.9, but I didn't check 4.14 since stintel's 4.14 patch for trunk didn't have it either Aug 06 07:39:35 jow: ping Aug 06 07:44:21 blogic: is there a way to find out these missing symbols like the buildbots do? Aug 06 07:46:02 no idea Aug 06 07:46:12 i rely on buildbots for that sort of stuff Aug 06 08:02:50 ok :) Aug 06 08:14:54 there's seems to be two concurrent firmware branches for the qca9984 numbered 3.5 and 3.6 Aug 06 08:15:04 does anybody know the difference between the two? Aug 06 08:15:58 the latest version of the former series is: QCA9984 hw1.0: 3.5.3.1: add firmware-5.bin_10.4-3.5.3.1-00006 Aug 06 08:16:09 and the latter: QCA9984 hw1.0: 3.6: add firmware-5.bin_10.4-3.6-00144 Aug 06 08:18:38 ml Aug 06 08:18:40 oops Aug 06 08:22:05 don't you just love qualcomm's numbering :( Aug 06 08:22:30 huaracheguarache: test it, 3.6 might require a version of ath10k net yet present in master (which is based on 4.14-rc2?) - unfortunately there is close to zero information (cough, changelogs, cough) about it Aug 06 08:23:40 I'm running it, and everything seems fine Aug 06 08:25:00 the lack of changelogs is very frustrating Aug 06 08:27:07 huaracheguarache: you could test my mac80211 update Aug 06 08:27:19 i have rebased mac80211 ontop of v4.18-rc7 Aug 06 08:27:20 I'd already be happy if they'd at least add "requires kernel >= x.y" Aug 06 08:27:37 pkgadd: my update also correates the FW used with the driver used Aug 06 08:27:59 blogic: last time i tried a tar file was missing causing an error during download Aug 06 08:28:00 basically i would like to see us not use some ancient random testing commit hash with some random fw blob Aug 06 08:28:09 but use latest stable with matching latest FW Aug 06 08:28:18 huaracheguarache: yes, i can mail it Aug 06 08:28:40 actually let me call jow and ask him to upload it to the mirroe Aug 06 08:29:06 4.18 will be next LTS right? Aug 06 08:29:29 i think v4.19/20 Aug 06 08:31:09 blogic: give me a heads up when it's ready and i'll take a look Aug 06 08:32:30 huaracheguarache: if you PM your mail addr i can send it over and you can copy it to your dl/ folder Aug 06 08:32:50 michael.yartys@gmail.com Aug 06 08:33:01 everyone knows it's me anyways =) Aug 06 08:35:27 on its way Aug 06 08:35:31 Hello all Aug 06 08:35:45 Should I use ULA prefix in my global setingS? Aug 06 08:36:21 blogic: thanks Aug 06 08:50:12 Have you tried simple-adblock recently? I think it blocks more than needed. Sometimes even openwrt.lan is not working Aug 06 08:52:22 Borromini: pong Aug 06 08:54:56 * f00b4r0 couldn't crash his mt7620 wifi, time to report to kernel bugzilla Aug 06 08:56:15 jow: a bunch of perl packages in 18.06 are presently inoperable because they are linked against the wrong version of perl Aug 06 08:56:50 DonkeyHotei: perl is managed in the pacakges feed Aug 06 08:56:57 needs to be fixed there Aug 06 08:56:59 yes Aug 06 08:58:08 but there needs to be a way to trigger a rebuild of certain pkgs even when they have not changed/bumped, because a dependency has, like this Aug 06 08:58:17 yes, increase PKG_RELEASE Aug 06 08:58:27 or manipulate the dependencies Aug 06 08:58:42 e.g. EXTRA_DEPENDS:=perl (>= 5.28.0) Aug 06 08:58:59 which would probably be a good idea anyway Aug 06 08:59:15 or make perl stage a perl.mk which extra perl modules can use Aug 06 08:59:39 the packages do not depend on a specific version of perl, they just have to be rebuilt when perl is bumped Aug 06 08:59:54 yes, and for that the makefile has to change Aug 06 09:00:07 don't care how, add a comment "rebuild perl" or bump the pkg release Aug 06 09:00:33 maybe that ABIVERSION thing could help too Aug 06 09:00:47 that should trigger a rebuild of dependant packages when it changes iirc Aug 06 09:01:04 a bit late to change the system for 18.06, gotta bump all the PKG_RELEASE's manually now Aug 06 09:01:36 nah, will add a hack to the buildbot Aug 06 09:01:56 still... needs to be fixed properly or it will occur every time perl is bumped Aug 06 09:02:10 as long as the makefile does not change it is not rebuilt Aug 06 09:02:29 or as long as another bit of info changes, I think ABIVERSION was introduced exactly for such cases Aug 06 09:02:52 atm everything perl-*.ipk has to be rebuilt Aug 06 09:08:34 blogic: flashed the mac80211 patch and all fine so far Aug 06 09:09:09 DonkeyHotei: the other problem is see is that opkg will never notice updates to those perl packages unless the version changes Aug 06 09:10:05 as long as the downloads are replaced with ones that work, that's probably ok Aug 06 09:10:17 DonkeyHotei: so either the packages need to be packages in a version agnostic manner (e.g. /usr/share/perl5 instead of /usr/lib/perl/5.26) or they need to somehow incorperate the perl version they link against into their own version Aug 06 09:10:30 *need to be packaged Aug 06 09:10:55 DonkeyHotei: its "probably okay" until perl is bumped again Aug 06 09:11:02 the former won't work, has to be the latter, like the perlbase pkgs Aug 06 09:11:03 then we're in the exact same situation Aug 06 09:11:16 you have extra work, I have extra work, there's new tickets and new furstrated users Aug 06 09:11:59 but I agree that replacing the packages now will at least fix it for those wo have not yet installed those packages Aug 06 09:12:11 the others need opkg install -force-reinstall perl-xyz Aug 06 09:12:59 maybe ABIVERSION should just go in the filename too Aug 06 09:13:13 in the future. Aug 06 09:13:41 yerah, I guess that would solve it completely Aug 06 09:13:51 blogic: btw, how's the pregnancy? )) Aug 06 09:14:27 or add some kind of version suffix, e.g. perl-lwp-mediatypes_6.02+perl5.26-1 Aug 06 09:26:44 dedeckeh: ping Aug 06 09:30:39 f00b4r0: ?! Aug 06 09:31:00 ah, now i get it Aug 06 09:31:07 please add V2 to prefix in future Aug 06 09:32:18 blogic: iforgot, appologies Aug 06 09:32:34 i thought you just resent the patch and was confused :-) Aug 06 09:32:50 i was focused on --in-reply-to and forgot --v2 ;P Aug 06 09:33:16 huaracheguarache: gotta ask psyborg Aug 06 09:33:50 jow:pong Aug 06 09:34:14 blogic: btw, 3 patches at the bottom of https://bugzilla.kernel.org/show_bug.cgi?id=82751 appear to stabilize mt7620 2.4 (for me). I've just mentioned that on that ticket Aug 06 09:35:30 blogic: hehe Aug 06 09:36:27 f00b4r0: ok Aug 06 09:38:45 dedeckeh: hi. I was wondering if the netifd local ipv6 prefix size reporting is fixed in master and 18.06 already Aug 06 09:39:00 dedeckeh: to close https://github.com/openwrt/luci/issues/1947 Aug 06 09:41:54 jow:it's fixed in master Aug 06 09:42:22 don't think the fix is present in 18.06 Aug 06 09:42:27 moment Aug 06 09:46:09 jow:fix is not present in 18.06; will take care of that Aug 06 09:49:39 I'd argue that it *should* be showing /64... because the underlying interfaces should be configured as /64 Aug 06 09:50:01 even if there's a /60 available to do downstream PD on, it's still not correct to configure the whole /60 as on-link on that interface Aug 06 09:50:49 of course that issue involves more than just the web interface :| Aug 06 09:53:48 Dagger:This will break prefix delegation to downstream routers a odhcpd picks up the prefix size depending on the prefix size it allows to delegate prefixes to downstream routers Aug 06 09:54:50 it shouldn't. you would just need to store the available prefix info somewhere in the filesystem Aug 06 10:39:01 jow: sorry. i forgot my question :'( Aug 06 11:59:22 217,327 additions, 0 deletions not shown because the diff is too large. Please use a local Git client to view these changes. Aug 06 12:00:24 a github PR trying to add a 1/4million line wifi driver Aug 06 12:00:44 blogic: would 72489ebeb65fd1e1d77e8d9fbe105827a98dbf03 be eligible for backports to 18.06 or even 17.01 ? Aug 06 12:01:23 thanks for the fast merge btw. Aug 06 12:03:09 rotanid: not sure Aug 06 12:27:19 Is therer any plans to change opkg to use https? Aug 06 12:33:44 HeMan: no Aug 06 12:35:42 jow: i remember now. with the lede ML being renamed to openwrt, pre-merge messages aren't available anymore either. is there a way to solve this? Aug 06 12:36:12 e.g. http://lists.infradead.org/pipermail/lede-dev/2016-October/003326.html gives 'forbidden' Aug 06 12:36:32 interesting, here it shows the archived message Aug 06 12:36:58 same with curl, so its not a cached browser credential thing Aug 06 12:37:37 weird :-/ Aug 06 12:37:52 note that http://lists.infradead.org/pipermail/lede-dev/2016-October/003326.html redirects to https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/003326.html (different host) Aug 06 12:37:56 same 403 pops up in chromium Aug 06 12:38:09 if I manually change openwrt-devel to lede-dev but keep lists.openwrt.org, then I do get 403 Aug 06 12:38:21 ok so i should just change my links then. thanks. Aug 06 12:38:46 the redirect works here... Aug 06 12:39:19 ah, i think i know the issue Aug 06 12:39:28 i'm not sure why it doesn't for me, since chromium is pretty standard. I made some tweaks to firefox, but not when it comes to redirects afaik. Aug 06 12:39:57 jow: do you have HTTP2 enabled on these hosts? the certificate contains both hosts, if they are on differen IPs, the browser doesn't know about this and tries the same IP with HTTP/2 to be faster Aug 06 12:40:02 build #76 of ramips/mt7620 is complete: Failure [failed images] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Fmt7620/builds/76 blamelist: Stijn Tintel , Chen Minqiang , Stijn Segers , Daniel Gimpelevich Aug 06 12:40:37 ^^^ drivers/net/ethernet/mtk/gsw_mt7620.c:171:14: error: 'mdio_mode' undeclared (first use in this function); did you mean 'd_move'? Aug 06 12:41:21 @ blogic Aug 06 12:41:59 rotanid: no idea, the list server is operated by david woodhouse Aug 06 12:42:21 sounds like one of these google "tweaks" Aug 06 12:42:46 and whenever those "tweaks" happen to break things, its not googles fault but existing hosts all have to change their behaviour to accomodate Aug 06 12:42:49 hm, no, they both use the same IP addresses, so that's likely not it Aug 06 12:43:00 only, if Borromini has different IPs in his cache or local resolver Aug 06 12:43:39 198.137.202.133 / 2607:7c80:54:e::133 Aug 06 12:45:55 same IPv4 here Aug 06 12:46:01 no IPv6. Aug 06 12:47:32 hm. maybe you've got something else cached. have you tried incognito mode? Aug 06 12:49:46 incognito produces the same Aug 06 12:50:14 jow: grml Aug 06 12:54:00 Borromini crome sucks I use firefox Aug 06 12:54:16 Tapper: i only used chromium for testing purposes. Aug 06 12:54:24 K Aug 06 12:54:30 not sucking google's tit no worries. Aug 06 12:54:35 haha Aug 06 12:55:15 There is 2 dudes that work for firefox that are blind like me so a11y fixs get put in all the time. Aug 06 12:55:29 :) Aug 06 12:56:09 we all know google did create chrome because of the sheer kindness it is instilled with Aug 06 12:56:42 s/did/did not/ Aug 06 13:16:11 jow, blogic: unfortunately f6d81e2 is kinda dependent on 5a6229a, even though the former would also be for 18.06, not so much the latter Aug 06 13:36:09 DonkeyHotei: and again we need to guess what you wnt us to know Aug 06 13:36:13 DonkeyHotei: try telling us Aug 06 13:38:27 f6d81e2 without the check for mdio_mode is more than likely going to cause a regression on the E1700 and the eval board. perhaps an edited form of 5a6229a might be indicated for 18.06, just without the patch to the missing dts file? Aug 06 13:42:32 how about i revert all of them and you send us a patch to apply instead Aug 06 13:43:56 an 18.06-specific patch? (i didn't author f6d81e2, just the change to it) Aug 06 13:54:31 jow, blogic: this should fix the 18.06 build: https://pastebin.com/Ur6NfRce Aug 06 13:57:21 (on top of the 18.06 HEAD) Aug 06 14:10:15 hi, does the psk2 key always has to be 8+ characters long? Aug 06 14:10:44 Or is this needed for other encryption settings as well? Aug 06 14:12:30 8+ is required by the wpa spec Aug 06 14:12:44 ok, I will update https://openwrt.org/docs/guide-user/network/wifi/basic#common_options1 Aug 06 14:14:44 done Aug 06 14:19:37 mwarning: 8..63 byte for cleartext, exactly 64 byte hex string for precomputed Aug 06 14:20:23 shorter or longer strings are invalid Aug 06 14:23:14 ok, will update Aug 06 14:24:17 blarrick: hi! Aug 06 14:24:34 hello DonkeyHotei! Aug 06 14:24:40 it has been a while Aug 06 14:25:23 in your absence, i took the liberty of contacting the patch authors from that old forum thread you found by e-mail directly Aug 06 14:27:28 the resulting patch was merged a few hours ago, but there is an issue with the dts entry for the second radio, with a fix forthcoming Aug 06 14:27:37 awesome Aug 06 14:28:13 your initiative is much appreciated Aug 06 14:28:51 I'll wait a bit longer then, rather than go with the 17.x Aug 06 14:29:29 I'm also ordering a serial cable to hook up in case things go south Aug 06 14:30:52 be advised that the result will still be subject to https://bugzilla.kernel.org/show_bug.cgi?id=82751 Aug 06 14:54:41 How to flash the Archer C7 V2 back to original tp-link firmware? Is that possible? Aug 06 14:54:53 it's possible Aug 06 14:55:24 use the "dd-to-factory" thing with "sysupgrade -n -F" Aug 06 14:56:53 my mistake, i had that backwards Aug 06 14:57:05 the correct procedure is at: Aug 06 14:57:14 https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500#return_to_factory_firmware Aug 06 14:57:44 but this was a question for #openwrt rather than #openwrt-devel Aug 06 15:01:16 not that easy Aug 06 15:02:12 hsp: openwrt itself comes with dd so with some handiness you don't even need a linux. Aug 06 15:02:21 or a unix. just make sure you do everything in /tmp/ Aug 06 15:02:33 nobody ever said anything was easy :) Aug 06 15:05:33 jow: how can i make the buildsystem include a library in staging/host/lib/ in the ImageBuilder? Aug 06 15:06:04 i've been trying this in various ways for several days now and kind find how this is supposed to work Aug 06 15:06:26 first i thought setting HOST_BUILD_PREFIX:=$(STAGING_DIR_HOST) does the trick Aug 06 15:06:29 and for executables it does Aug 06 15:06:33 but not so for libraries Aug 06 15:06:49 (i'm talking about libubox, libblobmsg_json and libjson-c) Aug 06 15:07:03 I guess you need to make tool builds of them or something Aug 06 15:08:53 libs are usually copied through bundle-libraries.sh, so you need to have an executable in bin/ that links the libs you want to have included Aug 06 15:09:33 so far that's how i thought it would work Aug 06 15:09:36 but somehow doesn't Aug 06 15:10:07 jow: ./staging_dir/host/bin/ucert Aug 06 15:10:07 ./staging_dir/host/bin/.ucert.bin: error while loading shared libraries: libubox.so: cannot open shared object file: No such file or directory Aug 06 15:10:37 interestingly, libblobmsg_json DID get included (and it comes from the same pkgbuild as libubox...) Aug 06 15:11:07 please pastebin the following: Aug 06 15:11:45 bash -x ./scripts/bundle-libraries.sh /tmp/foo ./staging_dir/host/bin/ Aug 06 15:12:18 maybe your ucert executable lacks an rpath, so libubox is reported as "(not found)" by ldd or similar Aug 06 15:13:57 sorry, bash -x ./scripts/bundle-libraries.sh /tmp/foo ./staging_dir/host/bin/ucert Aug 06 15:15:32 jow: https://gist.github.com/dangowrt/5526201f1109bf044954d383ef9c68f8 Aug 06 15:18:04 jow: [daniel@box lede]$ LD_LIBRARY_PATH=./staging_dir/host/lib ldd staging_dir/host/bin/.ucert.bin Aug 06 15:18:04 linux-vdso.so.1 (0x00007ffd651fe000) Aug 06 15:18:04 libubox.so => ./staging_dir/host/lib/libubox.so (0x00007f186fe94000) Aug 06 15:18:04 libblobmsg_json.so => ./staging_dir/host/lib/libblobmsg_json.so (0x00007f186fc91000) Aug 06 15:18:04 libjson-c.so.2 => ./staging_dir/host/lib/libjson-c.so.2 (0x00007f186fa86000) Aug 06 15:18:04 libc.so.6 => /usr/lib/libc.so.6 (0x00007f186f6ca000) Aug 06 15:18:06 /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f18702a5000) Aug 06 15:19:27 jow: seems like you are right, rpath is missing: Aug 06 15:19:36 [daniel@box lede]$ ldd staging_dir/host/bin/.ucert.bin Aug 06 15:19:36 linux-vdso.so.1 (0x00007ffeb3beb000) Aug 06 15:19:36 libubox.so => not found Aug 06 15:19:36 libblobmsg_json.so => /usr/local/lib/libblobmsg_json.so (0x00007f50ace9a000) Aug 06 15:19:36 libjson-c.so.2 => not found Aug 06 15:19:37 libc.so.6 => /usr/lib/libc.so.6 (0x00007f50acade000) Aug 06 15:19:38 /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f50ad2a1000) Aug 06 15:19:40 libubox.so => not found Aug 06 15:19:44 libjson-c.so.2 => not found Aug 06 15:20:01 ah and blobmsg worked because it happend to be present on your system Aug 06 15:20:06 exactly Aug 06 15:21:09 I think you will need to have an rpath Aug 06 15:21:25 so that ucert is executable in the buildroot Aug 06 15:21:43 to have it working in the sdk/ib you need the rpath so that dpeendant libs can be discovered Aug 06 15:21:46 is Archer C7 V5 supported, not found in database? Aug 06 15:25:06 hsp: check the forum Aug 06 15:27:10 dangole: is the hsot ucert tool working at all in buildroot context? I guess the missign rpath would make it unsuable there too, or am I missing something? Aug 06 15:27:56 dangole: e.g. a mere ./staging_dir/host/bin/ucert should print a summary or help and not crash, similar to e.g. tar or xz Aug 06 15:28:55 jow: it only works when setting LD_LIBRARY_PATH. i'm trying to get CMake to set the rpath Aug 06 15:29:03 the more i use it the less i like CMake Aug 06 15:29:11 :) Aug 06 15:29:17 all autconfiguration / build systems suck Aug 06 15:29:22 really, all of them Aug 06 15:29:23 true Aug 06 15:30:50 SET(CMAKE_INSTALL_RPATH "${STAGING_DIR_HOST}/lib") Aug 06 15:30:55 would be a sane setting Aug 06 15:31:01 or even Aug 06 15:31:13 SET(CMAKE_INSTALL_RPATH "$ORIGIN/../lib") Aug 06 15:31:21 but not sure about the esacping semantics Aug 06 15:37:57 jow: i kinda dislike the idea to leak OpenWrt-specific concepts (like $STAGING_DIR_HOST) into the CMakeList which belongs to the project. just seems wrong to me somehow. Aug 06 15:38:23 dangole: I didn't mean to do it literally Aug 06 15:39:53 dangole: you would do something like SET(USE_RPATH "" CACHE STRING "Override install RPATH") Aug 06 15:40:12 followed by IF(USE_RPATH) SET(CMAKE_INSTALL_RPATH "${USE_RPATH}") ENDIF() Aug 06 15:40:34 in your outer OpenWrt Makefile you then do Aug 06 15:40:50 CMAKE_OPTIONS += -DUSE_RPATH="${STAGING_DIR_HOST}/lib" Aug 06 15:41:27 maybe you can even do it right away using CMAKE_OPTIONS += -DCMAKE_INSTALL_RPATH="${STAGING_DIR_HOST}/lib" Aug 06 15:41:39 without adding further directives to your CMakeList.txt Aug 06 15:42:59 https://github.com/openwrt/openwrt/pull/915 :( Aug 06 15:44:07 why is there so much questionable stuff in this commit, mr. rockdrilla. Aug 06 15:45:03 salcedo: how so? Aug 06 15:46:38 + ecc_free(Q_them); Aug 06 15:46:40 + m_free(Q_them); Aug 06 15:46:49 - for (ix = 0; ix < (pa + 1); ix++) { Aug 06 15:46:51 + for (ix = 0; ix < pa; ix++) { Aug 06 15:47:06 CONFIGURE_ARGS += \ Aug 06 15:47:07 --disable-harden \ Aug 06 15:47:26 + $(if $(CONFIG_DROPBEAR_ECC),touch $(1)/etc/dropbear/dropbear_ecdsa_host_key) Aug 06 15:47:50 yeah this commit scares the shit out of me. i'm gonna use openssh. Aug 06 15:50:25 jow: -DCMAKE_SKIP_RPATH=TRUE is set in ${TOPDIR}/include/cmake.mk Aug 06 15:50:44 jow: i'll remove it, i guess it was copied from the defaults for package builds above (where it does make sense not to set rpath) Aug 06 15:50:50 dangole: then override it CMAKE_OPTIONS += -DCMAKE_SKIP_RPATH=OFF Aug 06 15:50:57 or FALSE, rather Aug 06 15:51:25 I'd rather avoid changing this globally for the moment Aug 06 15:53:30 jow: ok, that apparently does the trick. Aug 06 15:53:41 jow: thanks a lot for your help! Aug 06 15:54:01 we can consider changing the default but I'd ideally like to do it separately Aug 06 15:54:15 and after reviewing how it changes staging_dir/host/bin/ executables exactly Aug 06 15:54:40 the problem I see is that it will "leak" host paths to the SDK and IBs Aug 06 15:55:04 since iirc we're not stripping rpaths for host executables Aug 06 15:55:34 so ideally we should, when we reenable CMAKE_SKIP_RPATH, also set a relative $ORIGIN based rpath Aug 06 15:56:27 alternatively filter host utils staged in IB/SDK through patchelf Aug 06 16:02:07 [Mon 2018-08-06 05:40:02 AM PDT] build #76 of ramips/mt7620 is complete: Failure [failed images] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Fmt7620/builds/76 blamelist: Stijn Tintel , Chen Minqiang , Stijn Segers , Daniel Gimpelevich Aug 06 16:02:07 [Mon 2018-08-06 06:54:31 AM PDT] jow, blogic: this should fix the 18.06 build: https://pastebin.com/Ur6NfRce Aug 06 17:29:56 huaracheguarache, did you have some question for me? Aug 06 17:33:46 i didn't manage to get 802.11w to work with ath10k-ct in client mode Aug 06 17:34:07 i probably did something wrong somewhere along the way, but right now i'm unable to to more testing Aug 06 17:34:47 huaracheguarache, I'll make a note to re-test it locally, but it worked last time we tried it. Aug 06 17:35:23 we always use -htt-mgt firmware in our testing, btw...so please try that first and of course let me know of regressions etc. Aug 06 17:35:39 yeah, i tried that firmware Aug 06 17:36:15 this was on 988X (wave-1) hardware, right? Aug 06 17:36:36 mkresin: extending commit f9b8328 to the new .dts in the same manner as you did for the ArcherC20v1 produces this https://pastebin.com/rUwz3fqf as if the problem is in mt7620a.dtsi; does building for the ArcherC20v1 not produce these warnings? Aug 06 17:36:41 huuuuh, kernel build options don't appear to be picked up by diffconfig Aug 06 17:37:03 greearb_: yes, archer c7 v2 with QCA9880-BR4A Aug 06 17:37:11 thanks Aug 06 17:38:36 oh hm, it does, but defconfig adds it again as in diffconfig its commented out, not explicitly set to =n Aug 06 17:39:23 greearb_: does your firmware have any known speed issues? i tried it on my r7800 (qca9984) and speed tests were a lot slower than with regular ath10k Aug 06 17:39:45 also uh, who was saying about the freadahead.c thing? Aug 06 17:39:54 did I see it in here? Aug 06 17:40:05 oh hm, no Aug 06 17:42:27 huaracheguarache, it does not that I am aware of. Aug 06 17:43:21 please see if it is driver or firmware that has the issue, non-htt firmware should work with stock driver. I guess there might possibly be some 160Mhz issues with stock driver....are you running 160Mhz channels? Aug 06 17:43:39 no, 80mhz Aug 06 17:43:54 i was running ath10k-ct with htt firmware Aug 06 17:44:15 it works well for us, 1.3Gbps or so UDP download, about 1Gbps upload Aug 06 17:44:22 but of course it could still have bugs Aug 06 17:44:36 I'll re-test when I get the opportunity Aug 06 17:46:34 mkresin: confirmed, identical warnings are emitted when building for that device as well, after your commit Aug 06 17:47:18 mkresin: almost certainly all mt7620a devices are affected, at least Aug 06 17:48:08 greearb_: what benefits does the htt firmware give over the non-htt firmware? Aug 06 17:49:21 huaracheguarache, it is what we test with, so likely works in more strange cases, and also WMI (mgt/ctrl) commands to firmware won't be blocked in case some mgt frame is being retried (like when station dissappears abrubtly). Aug 06 17:50:07 That last part is hard to notice in most cases, but bigger environments showed it causing big trouble especially in wave-1 firmware. Wave-2 might be better, I am not sure. Aug 06 17:51:12 ok, thanks! Aug 06 17:58:42 DonkeyHotei: the ArcherC2-v1.dts isn't covered by my compile script, due to a different include style Aug 06 17:58:55 DonkeyHotei: let me fix it and try what fallout I see Aug 06 17:59:33 mkresin: are there any mt7620a dts files which it covers? Aug 06 18:00:16 DonkeyHotei: it covers all of them Aug 06 18:01:29 i said C20v1, but C2v1 could have the same problem. both are mt7620a Aug 06 18:02:32 DonkeyHotei: please confirm it before assuming something wrong Aug 06 18:02:57 i confirmed on C20v1 at least Aug 06 18:03:31 DonkeyHotei: let me check if I can reproduce the warnings related to your dts Aug 06 18:05:22 DonkeyHotei: nope, it is only your board: https://gist.github.com/mkresin/1ea08c5d37ccac9ba85d8ed40f726601 Aug 06 18:05:44 DonkeyHotei: wait wrong file uploaded Aug 06 18:06:38 DonkeyHotei: https://gist.github.com/mkresin/1ea08c5d37ccac9ba85d8ed40f726601 Aug 06 18:10:18 DonkeyHotei: device_type = "pci"; is only valid for pci bridges not for actual devices Aug 06 18:12:03 is the firstboot command supposed to work? Aug 06 18:12:21 doesn't it? Aug 06 18:15:57 jwh: https://pastebin.com/mdt2yDVa Aug 06 18:16:57 stat /overlay/upper/etc/modules-boot.d/54-usb-dwc2 Aug 06 18:17:00 mkresin: with the patch i've now staged, the direct invocation of dtc like in your script no longer issues the warnings, but "make V=s" still does, and not just for this board. confirmed for the C20v1, will now try the C2v1 Aug 06 18:17:00 date Aug 06 18:17:04 jwh: I wanted to perform a full factory reset according to https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset#soft_factory_reset Aug 06 18:17:38 ldir: ping Aug 06 18:17:48 jwh: give me a second, have to switch networks Aug 06 18:20:02