**** BEGIN LOGGING AT Tue Jul 24 03:00:01 2018 Jul 24 04:39:22 Hauke: do you (still?) have E3000? Jul 24 04:39:29 Hauke: https://bugs.openwrt.org/index.php?do=details&task_id=1688 Jul 24 04:53:02 rmilecki: I've a wrt610n which is very close (e3000 firmware can be flashed on it) Jul 24 04:53:33 jow: can you suspect anything specific from that report? Jul 24 04:53:39 it seems like just a hang Jul 24 04:53:45 not a crash, error Jul 24 04:53:57 jow: would you care to biesct that? Jul 24 04:55:17 can try Jul 24 04:57:53 rmilecki: do we have a last known working version? Jul 24 04:58:05 rc1 I believe Jul 24 04:58:10 mamarley: right? Jul 24 04:58:33 rmilecki: I have a wrt610n Jul 24 04:58:45 but I am currently traveling and forgot to test it before Jul 24 05:13:01 hi Jul 24 07:30:50 Hauke: i wrote a channel driver Jul 24 07:30:55 about 5 years ago Jul 24 07:31:05 i'll see if i can find it later on Jul 24 08:00:15 Hi all! I have a openwrt router running wifi, eth0 and eth1 (USB module). If I have a bridge with Wifi, eth0 and eth1 I get ~20Mbit/s wifi speed, if I remove the eth1 from the bridge I get ~80-100Mbit/s wifi speed. Any clues? Jul 24 08:02:12 alex___: blocking IO on the usb Jul 24 08:02:27 i'd say its expected Jul 24 08:03:31 ok, is there no way to fix it? or is it by design? Jul 24 08:05:02 get a router with more ethernet ports Jul 24 08:05:12 usb ethernet is not a good choice really Jul 24 08:06:14 alex___: get a switch? they are very cheap Jul 24 08:06:23 * rmilecki dealing with musl Jul 24 08:06:40 rmilecki: yikees Jul 24 08:06:47 rmilecki: wazzup with musl ? Jul 24 08:07:08 musl and its strptime doesn't support %F... that's fine, it' just an glibc alias Jul 24 08:07:09 I know, I just have it as an option. So as long as I dont use the USB-ethernet I have to disable it in the bridge? Jul 24 08:07:09 but why the heck they don't support %z :( Jul 24 08:07:35 in order to not reduce the wifi speed Jul 24 08:07:58 probably Jul 24 08:10:40 blogic, rmilecki: it´s a compact custom router with a multipurpose usb port. But I dont get why the Wifi speed gets affected? Why is the idle USB driver/eth1 reducing the wifi to wifi speed in the wifi network? Jul 24 08:11:19 if its bridged, then all packets are passed to the eth1 Jul 24 08:11:32 passing packets involves all that USB operation Jul 24 08:11:58 so MikroTik tells me they can boot their ipq4018 hardware without any board-specific kernel change that's covered by the GPL Jul 24 08:12:01 I could only expect bridge to ignore interfaces that are down... is there anything connected to your eth1 interface(s)? Jul 24 08:12:20 that seems impossible to me, anyone wants to chime in on that? Jul 24 08:12:41 no, thats the strange part. The speed is lower with nothing connected to USB Jul 24 08:13:45 alex___: you can try some debugging by tracing packets, or adding some prints to the network device driver into the xmit function Jul 24 08:14:19 or you could go the easier route and configure eth1 (usb eth) on a different internal network. Jul 24 08:14:32 that way you still have your usb ethernet, but it won't hurt your wifi Jul 24 08:17:25 EqUaTe, but then I wont have the usb ethernet on the same subnet as the wifi and eth0? Jul 24 08:17:59 do you really need it on the same subnet? routed access between them wouldn't suffice? Jul 24 08:19:04 I guess that could work... any links on doing this? :) Jul 24 08:19:31 there's likely something in the wiki.. Jul 24 08:22:33 ok, I´ll check, anyways thanks for the help :) Jul 24 09:25:02 jow: ccache install doesn't seem to have worked on 02/03 Jul 24 09:30:46 f00b4r0: ok, done now. Must have been on the wrong machine Jul 24 09:31:04 heh :) will keep an eye Jul 24 09:31:43 jow: you wouldn't have an opinion on mikrotik's claim that they can boot a linux kernel without having to provide GPL board-specific data Jul 24 09:33:29 it seems there are actually bugs in musl & time handling... Jul 24 09:34:01 strftime should only format a string, but it seems it can sometimes modify source struct Jul 24 09:35:26 f00b4r0: no opinion Jul 24 09:35:48 but I could imagine Jul 24 09:36:15 think that's even possible? Jul 24 09:36:15 all secrets nicely encoded in DT which is under a MIT or BSDish license Jul 24 09:36:20 ah Jul 24 09:36:30 *sigh* Jul 24 09:37:36 I'm sure DT makes a lot of hw vendors happy that way ;P Jul 24 09:44:21 jow: ccache working, thx :) Jul 24 09:50:31 they still use 3.3.x kernels, they suck anyway Jul 24 09:50:57 can you extract the DT from running kernel? Jul 24 09:52:31 jwh: they do on that topic but the hw is nice and cheap, hence my interest Jul 24 09:54:02 yup Jul 24 09:54:10 if only the good ones worked heh Jul 24 09:54:43 * jwh grumbles about 2011, 1100xAH2 Jul 24 09:54:44 :D Jul 24 09:55:18 heh :) Jul 24 09:56:53 nm though Jul 24 09:57:10 ar71xx and I don't think the target is even supported anymore for the latter Jul 24 10:04:51 jow: arg Jul 24 10:05:03 jow: the makefile overwrites "CC" Jul 24 10:05:10 ... tar-1.30// && CC="gcc" CFLAGS="-O2" ... Jul 24 10:05:31 * f00b4r0 pulls some more hair Jul 24 10:07:05 it happens for nearly all of the "tools" builds too: the wrapper is almost never used :( Jul 24 10:07:41 rmilecki: Yes, -rc1 "worked", ignoring the missing package and second boot brick problem, which is now fixed. Jul 24 10:09:00 I guess I will bisect then. Jul 24 10:09:55 mamarley: https://pastebin.com/dyqLtvGb Jul 24 10:10:04 mamarley: I suspect one of the two kernel bumps Jul 24 10:10:27 jow: seems like only libelf behaves "normally" :( Jul 24 10:10:43 the build for8 Jul 24 10:10:49 for* Jul 24 10:11:09 Ah, you beat me to it. Yeah, a kernel bump sounds right, given the lack of brcm47xx-specific commits during that time period. Jul 24 10:12:20 Wait, that's just a list of commits. OK, I will still bisect then. :) Jul 24 10:12:36 yeah sorry, wasn't clear Jul 24 10:14:59 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/arch/mips/bcm47xx/setup.c?id=v4.14.50&id2=v4.14.54 Jul 24 10:15:24 rmilecki: any idea about that change? Jul 24 10:15:46 no... Jul 24 10:15:54 it was something neither me or Hauke could review Jul 24 10:16:14 thats the only clearly bcm47xx specific change I can spot Jul 24 10:16:21 between 4.14.50 and 4.14.54 Jul 24 10:16:26 oh, it was acked by Hauke Jul 24 10:16:28 HOSTCC:=gcc Jul 24 10:16:29 HOSTCXX:=g++ Jul 24 10:16:34 that's in rules.mk Jul 24 10:17:47 jow: Hauke: mamarley: https://www.linux-mips.org/archives/linux-mips/2018-06/msg00027.html Jul 24 10:18:55 jow: ":=" takes precedence over environment, in makefiles, correct? Jul 24 10:19:18 rmilecki: I should apply this patch? Jul 24 10:19:26 rather revert it Jul 24 10:19:58 I thought it was already reverted, based on what jow posted earlier. Jul 24 10:20:59 f00b4r0: I think so Jul 24 10:21:23 mamarley: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/arch/mips/bcm47xx/setup.c?id=v4.14.54&id2=v4.14.50 Jul 24 10:21:28 mamarley: diff was reversed Jul 24 10:21:38 Ah, OK. Jul 24 10:25:02 jow: I'll try to propose a simple fix. Note that this also means that setting the env CC/CXX doesn't do what you think it does Jul 24 10:26:06 theres a .config option for that, no? Jul 24 10:26:15 at least for external toolchain prefix Jul 24 10:26:41 f00b4r0: CC / CXX controls which host gcc / g++ is symlinked into staging_dir/host/bin/{gcc,g++} Jul 24 10:27:10 HOSTCC / HOSTCXX is relative to PATH:=$(topdir)/staging_dir/host/bin:$(PATH) Jul 24 10:27:33 so... it's working? Jul 24 10:29:12 http://phase1.builds.lede-project.org/builders/lantiq%2Fase/builds/563/steps/ccachestat/logs/stdio Jul 24 10:29:14 apparently not Jul 24 10:30:29 jow: from what I read, the PATH does not include staging_dir/host/bin/ during either "dltar" or "tools" steps Jul 24 10:30:41 so apparently, the system-wide gcc/g++ are used? Jul 24 10:31:33 * f00b4r0 is very very confused by the build system, tbh Jul 24 10:32:16 feeds update is invoked with an incomplete env Jul 24 10:32:36 feeds udpate calls make prepare-tempinfo which performs host tool detection since its the first make invocation after deleting tmp/ Jul 24 10:33:14 http://phase1.builds.lede-project.org/builders/oxnas%2Fox820/builds/73/steps/updatefeeds/logs/stdio Jul 24 10:33:55 but we only want the wrapper to be used for dltar/tools steps? Jul 24 10:34:00 is that even possible then? Jul 24 10:34:04 no Jul 24 10:34:09 \o/ Jul 24 10:34:58 but whats wrong with using the host ccache for all steps? Jul 24 10:35:12 we discussed that at length Jul 24 10:35:20 too much variance? Jul 24 10:35:37 hold on Jul 24 10:35:40 i'm confused again Jul 24 10:36:00 let me read through build logs Jul 24 10:36:06 CC / CXX is used to build tools and to build the stage1 of the corss toolchain Jul 24 10:36:29 target builds will use other CCs anyway Jul 24 10:36:43 so that would only affect dltar, tools and toolchain steps? Jul 24 10:36:48 yes Jul 24 10:36:54 i suppose it can work Jul 24 10:37:10 toolchains is going to thrash around the cash due to significant variance from target to target though Jul 24 10:37:28 cache Jul 24 10:37:29 the we're better off with no ccache Jul 24 10:37:49 i don't know. We can try and see how the hit ratio goes Jul 24 10:37:55 tar build can be skipped if host system is linux and host tar is found to be recent enough Jul 24 10:38:14 but that was the reason why I initially wanted to restrict ccache to only dltar and tools. They both represent about 20% of the total build time Jul 24 10:43:26 jow: https://github.com/f00b4r0/owtbuildbot/commit/d00e396b1df81d5fbc1fabc3686b84661b78f357.patch Jul 24 10:43:41 should work if I understood your description correctly. Jul 24 10:45:33 it creates the wrappers before the updatefeed steps, sets correct env for updatefeeds, installfeeds and toolchain steps Jul 24 10:47:11 lets see Jul 24 10:47:23 it's possible it will still give good results since several targets share the same toolchains Jul 24 10:47:52 after a few builds the stats will tell us. Jul 24 10:49:06 jow: maybe then the fact that one tool seem to use the environment over the hard-set HOSTCC is a bug? Jul 24 10:51:33 possible, yes. Didn't look in detail Jul 24 10:51:37 checking for gcc... /var/lib/buildbot/slaves/slashdirt-02/oxnas_ox820/ccache_cc.sh Jul 24 10:51:43 from http://phase1.builds.lede-project.org/builders/oxnas%2Fox820/builds/73/steps/tools/logs/stdio Jul 24 10:52:00 hard to tell for sure which tool does that due to heavy parallelism Jul 24 10:52:49 i think it's libelf Jul 24 10:54:29 jow: you might want to check ownership of /var/lib/buildbot/.ccache, I suspect it might be wrong Jul 24 10:57:00 looks okay Jul 24 10:57:29 odd. http://phase1.builds.lede-project.org/builders/oxnas%2Fox820/builds/73/steps/ccachestat/logs/stdio shows nothing despite the wrapper seemingly being used by at least libelf Jul 24 10:58:52 it's possible it's a side effect of the incorrect initial setup. Let's wait before jumping to conclusions Jul 24 11:11:08 jow: I'm an idiot. You can in fact use the wrapper without using ccache. Jul 24 11:11:22 that's how i designed it in the first place ;P Jul 24 11:34:23 jow: color me daft but I don't see where the staging_dir-linked hostcc is taken from env. I've just done a quick local test and it still links to the system-wide gcc, regardless of what I set CC to... Jul 24 11:34:31 so I'm afraid the wrapper is not going to be used Jul 24 11:35:34 f00b4r0: yeah, theres a bug in prereq-build.mk Jul 24 11:38:07 jow: think you could fix it? I honestly don't understand how this work enough to figure out what's wrong Jul 24 11:39:36 Hey everyone! What's the most common way to log traffic in a public network on OpenWRT? Jul 24 11:39:36 To send the logs I understood that syslog-ng3 is recommended but how to log traffic itself? Jul 24 11:50:32 f00b4r0: seems to work now Jul 24 11:51:11 https://pastebin.com/wNgW2dQx Jul 24 11:52:49 buildbot@slashdirt-02:~/slaves/slashdirt-02/malta_be/build$ ls -lh staging_dir/host/bin/{gcc,g++} Jul 24 11:52:52 lrwxrwxrwx 1 buildbot buildbot 60 Jul 24 13:45 staging_dir/host/bin/g++ -> /var/lib/buildbot/slaves/slashdirt-02/malta_be/ccache_cxx.sh Jul 24 11:52:55 lrwxrwxrwx 1 buildbot buildbot 59 Jul 24 13:45 staging_dir/host/bin/gcc -> /var/lib/buildbot/slaves/slashdirt-02/malta_be/ccache_cc.sh Jul 24 11:57:15 rmilecki: jow: With that commit reverted, 18.06-rc2 boots fine on e3000. Jul 24 11:57:29 mamarley: thanks a lot for testing! Jul 24 11:57:36 No problem. Jul 24 12:00:16 what's the correct command to compile musl? I tried make toolchain/musl/compile V=s Jul 24 12:18:46 jow: awesome, thanks! Jul 24 12:31:14 i modified build_dir/toolchain-arm_cortex-a9_gcc-5.4.0_musl-1.1.16_eabi/musl-1.1.16/src/time/strptime.c and did "make V=s" Jul 24 12:31:45 i didn't find "strptime" in the output Jul 24 12:31:58 is that expected? Jul 24 12:36:36 rmilecki: i think you need to remove the stamp in staging_dir otherwise the build is considered up to date Jul 24 12:37:26 rmilecki: rm build_dir/toolchain-arm_cortex-a9_gcc-5.4.0_musl-1.1.16_eabi/musl/.built Jul 24 12:38:04 thanks, trying now Jul 24 12:38:47 rmilecki: make toolchain/musl/compile V=s Jul 24 12:39:56 works! Jul 24 12:42:45 hi, its me with the bridge issues again... Turns out the bridge didnt affect the speed and that my router is randomly dropping from 144Mbit/s RX/TX rate to 24Mbit/s, any clue how? signal strenght 100% 802.11n Jul 24 13:01:01 jow: http://phase1.builds.lede-project.org/builders/ipq806x%2Fgeneric/builds/919/steps/ccachestat/logs/stdio something is definitely not working Jul 24 13:11:36 jow: i can investigate if you shutdown the VMs (can't access their filesystem otherwise) Jul 24 13:15:22 f00b4r0: yes, the problem is that the buildroot overrides CCACHE_DIR Jul 24 13:15:40 f00b4r0: unlink("/var/lib/buildbot/slaves/slashdirt-02/MAIN/build/staging_dir/host/ccache/7/c/b19151e5dca77bb58d84d832e710aa-68841.o.tmp.stderr2.slashdirt-02.13057") = 0 ... Jul 24 13:16:02 the old prepccache.sh did take care of that by symlinking iirc Jul 24 13:16:07 sigh Jul 24 13:16:29 i really don't like how intrusive and hardcoded this is but I suppose we have to make do Jul 24 13:16:41 can be probably changed Jul 24 13:17:57 really odd part is, these overrides should not apply since CONFIG_CCACHE is disabled Jul 24 13:19:51 jow: include/host-build.mk:135: $(1) : export CCACHE_DIR:=$(STAGING_DIR_HOST)/ccache Jul 24 13:21:02 i suppose we want to make that dependent on CONFIG_CCACHE Jul 24 13:22:26 which I already did Jul 24 13:22:38 currently doing test builds Jul 24 13:22:43 ah thanks Jul 24 13:23:22 btw I'm curious: did you change the buildbot config or are some environment variables carried over from one step to the other? Jul 24 13:23:24 see http://phase1.builds.lede-project.org/builders/lantiq%2Fxway/builds/946/steps/kmods/logs/stdio Jul 24 13:23:29 CCXX and CCC are still set Jul 24 13:23:45 yes I did, otherwise the build will fail Jul 24 13:23:52 interestingly, that setup, with CCACHE empty, is exactly what we need to disable ccache for e.g. toolchain Jul 24 13:23:58 ah ok Jul 24 13:24:00 makes sense Jul 24 13:24:05 since the wrapper is symlinked as gg it will fail when invoked without CCC Jul 24 13:24:13 *symlinked as gcc Jul 24 13:24:15 yeah i understand Jul 24 13:24:52 well then, i you disable tryccache=true for toolchain you will disable ccache there. But let's see first how it performs with it maybe :) Jul 24 13:25:14 * f00b4r0 needs to find a copy of "writing makefiles for dummies", the syntax used in the build system is way above his head Jul 24 13:27:05 its way above what should be done with make in the first place Jul 24 13:27:15 heh ok. I feel a bit less stupid then ;) Jul 24 13:53:30 lantiq,xrx200 - kmod-ath9k-htc with ar9721 wifi dongle doesnt work. "ath: phy1: Mac Chip Rev 0x0f.3 is not supported by this driver" any ideas? if not, better try the mailing list or the bugtracker? Jul 24 14:05:30 is it possible to do a proxy arp between wireless/lan and wan interfaces? Jul 24 14:06:10 rsd: relayd is what you prolly want Jul 24 14:07:11 let me check Jul 24 14:10:59 yep! thanks! Jul 24 14:32:47 jow: seems to be working now! thanks for fixing! Jul 24 14:40:53 jow: speedup is approx 45% for 'tools'. Neat! Jul 24 14:43:10 'dltar' is a more modest 25% boost. Still largely positive Jul 24 17:01:06 Hi all, how do you detect when a ethernet cable is plugged or unplugged in the switch? Jul 24 17:07:51 my switch activates a 577THz transmitter. I was born with two receivers that pick up on these transmissions and allow me to detect when a cable is plugged in. Jul 24 17:27:11 cshark-2015-11-24-e575ab3d35d75a6f70488001fcba45690ebe9b3e/src/uclient.c:170:50: error: '%s' directive output may be truncated writing up to 1023 bytes into a region of size 1007 [-Werror=format-truncation=] Jul 24 17:27:11 snprintf(extra_tags, BUFSIZ, "?additional_tags=%s", config.tags); Jul 24 17:27:13 gcc8 fun Jul 24 17:48:30 you mean when it finds latent bugs? is that meant to be a bad thing? Jul 24 18:28:50 karlp: i like that new stuff Jul 24 18:34:55 ^^^^^^^^^^^^^^^^^^^^^^^^^ Jul 24 18:37:29 * karlp too, it's awesome. Jul 24 18:43:21 just hold on to this while I write past the end of this buffer..... cheers. Jul 24 18:46:37 right, enough for 1 day Jul 24 18:46:50 refactored 2/3 of our ipq4019 codebase Jul 24 18:47:11 tomorrow i'll push that stuff upstream and then move on to the ethernet part Jul 24 19:00:03 * huaracheguarache cheers =) Jul 24 19:01:29 blogic: Thank you for that work, my router will be happier :) Jul 24 19:01:58 Let me know if you need testers, I have an ipq4018 device Jul 24 19:04:57 Hi all :) I'm trying to build OpenWRT master (with a few patches) and getting the opkg "Cannot satisfy the following dependencies for" for lots of kmods Jul 24 19:05:15 all of them "kernel (= 4.14.54-1-c1b145e0e478ece4512e1a06f111e72a)" Jul 24 19:05:45 I wonder whether there's something I need to do to make them build for the kernel I'm building at the same time? Jul 24 19:27:48 luaraneda: which one ? Jul 24 19:27:53 does it have usb3 ? Jul 24 19:28:02 i rewrotew the usb3 phy driver and dont have HW to test it Jul 24 19:45:56 blogic: an ASUS RT-AC58U. I assume it has an usb3 port (blue) Jul 24 19:47:17 I can perform tests at night, to avoid disturbing internet access Jul 24 20:41:44 ldir: he.net ddns is working for me, both IPv4 and IPv6 Jul 24 20:42:20 rmilecki: I have a wrt610nv1 around, if you need testing Jul 24 20:54:43 pkgadd: ha yeah - it spontaneously fixed itself about 4 hours after I'd noticed. Problem at he end Jul 24 21:15:27 pkgadd: thanks, we already found a regression thanks to jow's research and mamarley's testing Jul 24 21:15:36 i still need to find a moment to report ir Jul 24 21:15:46 I'm really busy recently Jul 24 21:15:50 o.k. Jul 24 21:20:38 so after changing the -W options (yes, lazy fix) for cshark and mmc-utils, and using the grub2 patch that has an open pull req, finally have a working gcc8 build Jul 24 21:27:36 is there an easy way to list selected packages from a specific feed? Jul 24 21:31:47 nyt: wget -qO- http://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages | awk '/^Package\:/{print $2}' Jul 24 21:32:27 that will list all the package names from a feed Jul 24 21:32:31 not the ones selected in build config Jul 24 21:36:55 was just trying to see what i was using from oldpackages Jul 24 21:37:01 look like just ngrep Jul 24 21:41:37 run a diffconfig and save the output, disable the oldpackages feed, reconfigure by running 'make config' again, run diffconfig and save output, diff both. Jul 24 21:41:58 yeah just did that already Jul 24 21:42:08 ok :) Jul 24 21:42:22 copying ngrep into regular feed lol Jul 24 21:42:34 finally ditching oldpackages Jul 24 21:44:25 jow: ping Jul 24 21:44:38 that command kind of helps: rm build_dir/toolchain-arm_cortex-a9_gcc-5.4.0_musl-1.1.16_eabi/musl/.built Jul 24 21:44:54 i can see related files being rebuilt by make toolchain/musl/compile V=s Jul 24 21:45:03 then I follow with make V=s and... nothing Jul 24 21:45:09 my image still uses old musl Jul 24 21:45:19 any idea what else I need to do? Jul 24 21:45:22 ping nbd ^^ Jul 25 00:20:55 is there any awareness of iwd (internet wireless daemon, from marcel holtmann, et al) in openwrt land? Jul 25 00:21:02 https://linuxgizmos.com/new-linux-wireless-daemon-seeks-cleaner-connection/ Jul 25 00:35:24 russell--: last time I looked, and that admittedly has been quite some time ago, iwd wasn't really production ready - and I would still expect quite some surprises in production use, when it comes to real-world wifi interoperability with crazy vendor drivers running on the different clients you will experience in the real world Jul 25 00:48:23 pkgadd: i saw his 2017 elc talk, at a point where it seemed pretty client-centric, but i noticed some recent commits where it seems to support ap-mode Jul 25 00:56:44 yes, AP mode came later and I don't really know how complete it's supposed to be at the moment Jul 25 02:48:01 russell--: ping **** ENDING LOGGING AT Wed Jul 25 03:00:02 2018