**** BEGIN LOGGING AT Fri Dec 21 03:00:02 2018 Dec 21 03:13:27 build #1117 of lantiq/xrx200 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/lantiq%2Fxrx200/builds/1117 Dec 21 03:32:47 build #1126 of brcm2708/bcm2709 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2709/builds/1126 Dec 21 03:33:46 build #1114 of brcm2708/bcm2708 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2708/builds/1114 Dec 21 03:55:03 build #707 of at91/sama5d3 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d3/builds/707 Dec 21 03:58:35 build #1101 of octeon/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/octeon%2Fgeneric/builds/1101 Dec 21 04:05:40 build #254 of at91/sama5d4 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d4/builds/254 Dec 21 04:13:17 build #130 of samsung/s5pv210 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/samsung%2Fs5pv210/builds/130 Dec 21 04:17:20 build #253 of at91/sama5d2 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/253 Dec 21 06:01:52 sigh Dec 21 06:02:05 busybox ip -6 doesn't actually do ipv6, at least for the tunnel command Dec 21 06:09:11 does toybox? Dec 21 06:12:00 umm Dec 21 06:12:10 no idea but not at all relevant to openwrt I fear Dec 21 06:12:12 ;) Dec 21 06:15:39 nm, I'll just have to build images with ip-full Dec 21 06:16:03 also means if I'm gonn unify tunnel stuff its gonna have to depend on ip-full unless someone adds support to busybox Dec 21 07:20:02 'lo Dec 21 07:21:37 morning Dec 21 08:16:41 gch981213, morning, i managed to build a firmware gor that archer c5 v4, *but* i didn't know the hardware id of the unit so i can't flash it :| Dec 21 08:45:17 nitroshift: I guess it can be found in tp-link factory firmware. tplink-safeloader is a firmware header tp-link uses outside China and I don't know much about this one. (Here in China they uses another header with RSA signatures for almost every partitions...) Dec 21 08:48:26 gch981213, i'll give binwalk a go on the official firmware Dec 21 09:02:12 nitroshift: just noticed that tplink-safeloader utility in OpenWrt has the ability to extract the firmware and you can find the information you need from extracted files. Dec 21 09:06:55 gch981213, i've extracted the squashfs from the official firmware, no sign of hw id in it though Dec 21 09:10:15 nitroshift: extract factory firmware with tplink-safeloader utility and I think the support-list file is what you need. Dec 21 09:11:31 gch981213, i can see a support_3g_list Dec 21 09:12:12 it's not a file extracted from squashfs. that file is part of the firmware header. Dec 21 09:13:39 never used the sideloader thingie... Dec 21 09:13:51 *safeloader Dec 21 09:14:00 where can i get it? Dec 21 09:15:00 If you've compiled OpenWrt it's in staging_dir/host/bin/ (Source code for it is in tools/firmware-utils) Dec 21 09:18:10 build #1163 of at91/legacy is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Flegacy/builds/1163 Dec 21 09:21:36 gch981213, running the safeloader i get "no board has been specified: Succes" and that's it Dec 21 09:25:05 nitroshift: Should be: tplink-safeloader -x {OEM firmware name} -d {destination directory} Dec 21 09:25:25 nitroshift: tplink-safeloader -h will show you the usage. Dec 21 09:26:35 DEBUG: can not find fwuphdr Dec 21 09:27:43 Error can not read the partition table (fwup-ptn): Success Dec 21 09:28:23 the firmware contains the u-boot section too, could that be the issue? Dec 21 09:44:15 no, it wasn't that, i've stripped it Dec 21 09:50:12 nitroshift: That utility needs a firmware with correct header information (e.g. one downloaded from tp-link website). It doesn't work with a firmware dumped from SPI flash. Dec 21 09:50:43 gch981213, i'm working with a downloaded firmware Dec 21 09:53:32 nitroshift: If so I assume this device doesn't use a tplink-safeloader header :( Dec 21 09:55:53 gch981213, there is a "reduced_data_model.xml" file in the extracted firmware Dec 21 09:56:11 but i can't open it in a human-readable form Dec 21 10:00:29 jow: do you think a dependency on ip-full for a unified tunnel thinger is ok? Dec 21 10:00:39 jwh: no Dec 21 10:00:46 oh Dec 21 10:00:46 it is absolutely not Dec 21 10:00:55 well then we can't have working ipip anyway, coz busybox ip sucks Dec 21 10:00:56 :( Dec 21 10:01:27 I can't see any busybox options that add the functionality, it just appears to be missing entiely Dec 21 10:01:31 entirely* Dec 21 10:01:34 that'd be like +200KB for he.net tunnels which currently fit into like 2.5KB Dec 21 10:01:50 tbh I was gonna leave 6in4 as it is, since it also does dns things Dec 21 10:02:02 same for 6to4 (1.8KB atm) Dec 21 10:02:04 the existing ipip package isn't installed by default Dec 21 10:03:13 problem is, for the 'tunnel' subcommand, busybox has no v6 support Dec 21 10:03:22 or vti, or gretap Dec 21 10:03:24 etc Dec 21 10:11:55 guess I could add missing bits to netifd Dec 21 10:12:05 theres only 1 actually I think Dec 21 10:34:04 morning Dec 21 10:36:41 build #1153 of mpc85xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/mpc85xx%2Fgeneric/builds/1153 Dec 21 11:20:50 hey :) is it posible to make a vanilla room that install from usb or from a webscript ? Dec 21 11:22:26 like go to www.openwrt.router-autoinstall.tk , and follow the script ? Dec 21 11:22:50 doesn't look like malware at all Dec 21 11:25:59 it was just a exempel... Dec 21 11:26:18 it would be a way to have a up to date install .. Dec 21 11:26:29 and the server can be lokaly .. Dec 21 11:27:43 you probably want config management, I think openwisp does some of what you want Dec 21 11:30:08 i also want a list over the stuff you need for booting and start installing stuff Dec 21 11:32:11 this https://github.com/openwrt/openwrt/pull/1661/commits/ac3aecc5238e8a9c53aa602e1bdcd62471553cf0 seems like a great idea, but I can't work out why I think it's the wrong approach. Dec 21 11:33:19 ldir: why'd you think so ? Dec 21 11:33:40 conffiles is the correct way of preserving file during sysupgrade Dec 21 11:34:10 I can't put my finger on it, but somehow defining conffiles for busybox feels odd. Dec 21 11:35:38 pfft, I'm really gonna have to debug that dnsmasq static lease problem; now my workstation also started showing the same behaviour Dec 21 11:35:49 and I'm leaving for the airport soon Dec 21 11:36:02 how does it work if another busybox utility needs to preserve a config file? Dec 21 11:36:05 gonna switch it to static IP until I'm back Dec 21 11:53:39 jow: Hauke: my two patches that should help with USB 2.0 regression were accepted by Linus (pinctrl maintainer) Dec 21 11:53:50 i'll backport them as they get pushed Dec 21 11:54:07 (it's a regression I want to fix before the next 18.06 release) Dec 21 11:56:03 stintel: lease/ip gets declined on boot? Dec 21 11:56:41 KanjiMonster: yeah Dec 21 11:57:00 ldir contacted dnsmasq ML about it but I have yet to figure out what the reply meant Dec 21 11:57:19 having the same issue here with my vm Dec 21 11:58:58 ldir: the approach is okay but needs work Dec 21 11:59:29 ldir: he also need to ship an initial sysctl.conf (otherwise changed config file tracking will not work) Dec 21 12:00:05 ldir: and extend the busybox package makefile to install the shipped sysctl.conf when ifneq ($(CONFIG_BUSYBOX_$(BUSYBOX_SYM)_SYSLOGD),) Dec 21 12:00:25 KanjiMonster: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012607.html Dec 21 12:01:32 stintel: translation: "go away, as far as possible, and don't come back" Dec 21 12:01:36 ツ Dec 21 12:02:12 there are less arrogant ways to state "I need more input to understand the issue" Dec 21 12:02:54 didn't even see the reply from that Geert dude Dec 21 12:04:23 Geert really doesn't help that list at all. I find his replies unhelpful at best. Dec 21 12:04:34 stintel: seems to be a bit different to what I'm seeing -> https://pastebin.com/VvqXH9yf (haven't debugged that yet) Dec 21 12:07:21 stintel: in this case the decline comes fom the client, not the server - but something makes it think the address isn't available/usable Dec 21 12:07:30 oh :/ Dec 21 12:07:58 waiting 10m for the timeout, then ifdown/ifup'ing the interface then works Dec 21 12:08:18 (or restarting dnsmasq and immediately refreshing) Dec 21 12:09:19 I wonder if these have a common source though, like somewhere the duplicate address detection of dnsmasq and the client interfering with each other or so Dec 21 12:09:27 dumbass first reply to that message Dec 21 12:09:34 at least simon sent a sensible reply Dec 21 12:09:53 KanjiMonster:do you observe arp request from the client for the given IP address ? Dec 21 12:10:20 dedeckeh: "(haven't debugged that yet)" Dec 21 12:13:04 and downright patronising offensiveness at worst. I'm being polite. Dec 21 12:13:16 yes Dec 21 13:12:56 mac of 00:11:22:33:44:55 is interesting...is this as per capture or redacted in some way? I'm pondering leasefiles, vlans and cross-contamination of leasefiles. Think out of the box really. Dec 21 13:13:03 ldir: redacted Dec 21 13:13:34 as is the subnet Dec 21 13:16:44 I have no idea. I wish I did. :-( Dec 21 13:18:26 I have many statically assigned dhcp addresses and don't see this problem. Dec 21 13:23:34 frustrating. Dec 21 13:34:41 jow: rmilecki: I hope paulburton will create some fix for the executable and writable stack mapping on MIPS CPUs in the next few weeks, I think the dealine of 12. Jan for the release is ok Dec 21 13:35:40 FYI the fix is currently in mips-next Dec 21 13:38:54 git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git mips-next Dec 21 13:39:06 commit adcc81f148d7 ("MIPS: math-emu: Write-protect delay slot emulation pages") Dec 21 13:39:47 note that this isn't about the stack though - to make that no-exec is up to the toolchain emitting a non-executable PT_GNU_STACK header Dec 21 13:40:36 jow:ping Dec 21 13:43:52 paulburton: wouldn't the latter also require rixi support to be effective? don't think anything except octeon supports it in the OpenWrt supported platforms Dec 21 13:45:02 right, but there's nothing we can do about it if the hardware doesn't support non-executable pages Dec 21 13:45:45 at least nothing I'd consider practical Dec 21 13:46:25 emulate *all* the instructions! ;D Dec 21 13:46:54 was more as an argument why waiting for that would be rather pointless for OpenWrt Dec 21 14:08:48 dedeckeh: pong Dec 21 14:36:41 KanjiMonster: I think more CPUs support RIXI Dec 21 14:37:15 octeon only has some spcial method to detect it Dec 21 14:37:41 the toolchain already sets the PT_GNU_STACK header correctly Dec 21 14:37:49 at elast in master Dec 21 14:37:52 *least Dec 21 14:37:58 paulburton: thank you for the patch Dec 21 14:49:35 Hauke: I'm only talking about those we support in OpenWrt, and I'm not aware of any having RIXI support (feel free to correct me) Dec 21 15:16:56 KanjiMonster: if rixi is not supported, shouldn't all sections in /proc/self/maps be set to x ? Dec 21 15:17:22 at least on lantiq I see that the stack is is onl marked rw not x Dec 21 15:40:10 Hauke: without/with patch on my archer c7 https://pastebin.com/YP0UBqkJ Dec 21 15:41:21 7fefb000-7fefc000 segment no longer has write access. Dec 21 15:42:45 Hauke: it's the same for bmips3300 which is basically a 4kc - and I'm 99.9% sure it doesn't support rixi Dec 21 15:42:54 (bcm6348) Dec 21 15:43:24 ok Dec 21 17:07:50 greearb: wut? :O but that's during boot-up (mentioning the OOM on the bug) Dec 21 17:09:27 yeah, firmware allocates all memory at bootup, or at least most, and the rest very soon after bootup Dec 21 17:09:33 qca fw that is Dec 21 17:11:23 among other fun, that means that any memory scribble at any valid physical memory location will not crash (immediately).. Dec 21 17:17:23 weird, i never had to do that :F Dec 21 17:17:53 that FW must be compiled with some extra options vs stock, or something like that. In later commits I put the FW on a diet Dec 21 17:18:13 wait, does openwrt even support modprobe.d ? Dec 21 17:18:39 I think so, and if not, you can manually modprobe Dec 21 17:19:09 or, you can use the 'fwcfg' option to set the value per NIC...google on my page for fwcfg API...it shouldn't be overly difficult Dec 21 17:22:15 greearb_: nope, still falls flat on it's face Dec 21 17:22:31 plz show me dmesg Dec 21 17:22:50 greearb_: https://pastebin.com/1u6AKeqZ Dec 21 17:23:08 [74702.181410] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 528 tid: 102 Dec 21 17:23:20 whatever you did didn't work, it should be using 4 vdevs instead of 16 Dec 21 17:23:30 ah right, sorry Dec 21 17:26:28 grr, i'm doing insmod ath10k_core num_vdevs_ct=4 ; insmod ath10k_pci but i'm still seeing [74943.396393] ath10k_pci 0000:01:00.0: 10.4 wmi init: vdevs: 16 peers: 528 tid: 102 Dec 21 17:27:24 maybe try fwcfg method? Dec 21 17:46:47 greearb_: aight, got them loaded in. however, you said this fw is pretty stock, weird that this had to be done Dec 21 17:52:32 I don't know exact way stock is compiled, that could be the issue. Dec 21 17:53:03 Hey guys, does anyone know a way to flash OpenWRT to a Phicomm k3 b1? Dec 21 17:53:13 greearb_: anyway, the fw works Dec 21 17:53:28 as in the ps4 doesn't complain now Dec 21 18:11:33 I updated that bug with a link to 950+ images..one for each commit, shouldn't be too bad with log(n) bisect logic. I appreciate your effort in this! Dec 21 18:20:06 greearb_: thanks. i'll play withh it over the weekend. likewise, i appreciate you not being mad that i keep pestering you with those, since nobody's paying you for thhis Dec 21 18:20:21 also my damn macbook keyboard needs to obviously be replaced, AGAIN Dec 21 18:41:38 greearb_: btw why are you giving me -htt builds? I've never actually got the usecase for a common user for these? Dec 21 18:42:41 it is what you were testing, ct driver enables it by default...it helps with responsiveness in high congestion environments Dec 21 18:43:09 or rather, when you configure ct-fw in your openwrt makefile, you must have enabled it Dec 21 18:47:20 greearb_: no, there are 2 options in the makefile, one for -ct and one for -ct-htt, and the non-htt is the default Dec 21 18:49:36 as can be seen here https://cloud.movishell.pl/s/TBRtc8PcK9JYooX Dec 21 18:56:53 ahhh, I see...I mixed up your bug with another. Either way, likely the bisect will be proper. Please try the very latest just to make sure the problem still happens Dec 21 18:57:17 dedomraz: broadcom radio == super-ick, afaik Dec 21 18:57:23 it takes all day to rebuild those, but I can kick off a script if the HTT mgt ones are not bisecting properly. Dec 21 19:18:37 greearb_: Need you a meatier build box Dec 21 19:24:05 heh heh you said meat Dec 21 19:27:16 the firmware makefile blows up if you try to build it parallel, so...yeah... Dec 21 19:29:40 is anyone signed up to the forums (I'm not)? I sent an upstream fix for this issue: https://forum.openwrt.org/t/f2fs-on-usb-stick-does-not-work/27156/4 -> https://lore.kernel.org/patchwork/patch/1027286/ Dec 21 19:30:35 just in case anyone cares - I hope that the fix will hit -stable soon(tm) and from that on it's only a few days (typically) until it hits the OpenWrt tree :) Dec 21 19:33:28 jow: ping Dec 21 21:05:35 i flash from the "recovery webpage" but now its "dead" like only power light is on or showing "yellow\green" thats "inbootprosses" i flash from the "recovery webpage" but now its "dead" like only power light is on or showing "yellow\green" thats "inbootprosses" Dec 21 21:06:38 https://oldwiki.archive.openwrt.org/_media/media/doc/cfe63xx_web-upgrade.png?cache=&w=854&h=428&tok=84d258 Dec 21 22:28:20 zorgXx: what device? which image? Dec 21 23:40:31 a inteno eg400 .. i have two Dec 21 23:40:45 and it was a factory image i think lol Dec 21 23:43:08 build #1186 of brcm47xx/generic is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/brcm47xx%2Fgeneric/builds/1186 blamelist: Hans Dedecker Dec 22 01:22:19 zorgXx: if you are going to try to get openwrt working on an unsupported device, a serial console is strongly advisable **** ENDING LOGGING AT Sat Dec 22 03:00:02 2018