**** BEGIN LOGGING AT Thu Nov 08 02:59:59 2018 Nov 08 03:37:01 i built a x86_64 image and added luci-base and luci-mod-admin-full but there is no http server listening for connections, what did i forget to add to my image? Nov 08 03:40:35 CONFIG_PACKAGE_luci=y, which is just an empty meta package also pulling in uhttpd Nov 08 03:47:51 thanks, next time can i just install the uhttpd package along with the rest of the build and it will work? Nov 08 03:49:02 should work, yes Nov 08 03:50:14 heh nm im a idiot, i thought i turned on luci under collections but i missed that some how Nov 08 03:58:25 did you ever find how to switch ath9k to the other antenna connectors? Nov 08 04:18:47 nope he said it used to be done in house (atheros coding) but those people have moved on and they leverage support from qualcomm for driver modifications Nov 08 04:19:03 i just had to swap the antennas to all main Nov 08 04:19:46 :( Nov 08 04:20:18 yeah i found a reference to some of it in the source i was given **** BEGIN LOGGING AT Thu Nov 08 04:57:30 2018 **** BEGIN LOGGING AT Thu Nov 08 05:12:34 2018 Nov 08 05:47:25 . Nov 08 07:04:48 what is the normal way of figuring out how to create a "factory" image? Nov 08 07:05:12 that is, an image that the web interface from stock firmware will accept? Nov 08 07:06:43 i've tried a couple routes for this skylab skw92a device (uploading sysupgrade image to web interface, using mtd_write on the sysupgrade image), neither worked. Nov 08 07:45:09 blogic:ping Nov 08 08:45:59 goddamnit, right at the moment I need to very urgently print something that fscking dnsmasq assigned a wrong IP to my printer Nov 08 08:46:00 grrr Nov 08 09:20:29 oh, well, that's interesting. it seems something is telling the stock fw that the flash is only 4MB. Nov 08 11:05:39 russell--: the first step would be to unpack the OEM update image to understand the format. Then you can analyze the OEM's update process, it should be scripts doing some checks and finally writing the partitions Nov 08 11:16:32 luaraneda: /me discovers the truth by punching himself repeatedly in the face Nov 08 11:17:06 the 4MB indication was due to leaving the SOIC clip from the external programmer connected to the flash Nov 08 11:17:26 after removing, mtd_write method worked with the sysupgrade image Nov 08 11:18:41 the web interface does seem to be doing some kind of header check, but from a MIPS cgi-bin binary Nov 08 11:19:44 my work around for now is to use the web interface's upload tool to get the file onto the device, then telnet in and use mtd_write. Nov 08 12:42:34 build #621 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/621 Nov 08 13:51:31 jow: ping Nov 08 13:51:58 jow: quick questiong regarding the buildbot Nov 08 13:52:44 jow: Is it intended that each target gets another build queued on each commit being done? Nov 08 13:53:11 jow: add this moment, some targets have 5 builds queued (~5 separate commits have been made today) Nov 08 13:53:38 xback: yes, they'll get coalesced Nov 08 13:54:15 so they will build each separate commit, and not the "latest state" when the build starts? Nov 08 13:54:47 when the next build starts it'll build the latest state of the tree, regardless of whats in the build requests Nov 08 13:55:04 it will also invalidate (or "finish") all build requests pending at this time Nov 08 13:55:32 so it will build the latest tree, once asap and cancel all five pending requests Nov 08 13:56:24 ok thanks. I'll keep an eye on it. I checked it a few days ago. and some targets just builded 3 instances in a row, without any change to master Nov 08 13:56:57 the pending queue dropped by 1 on each build Nov 08 13:57:41 this does not look like what is supposed to happen Nov 08 13:57:48 but will check later Nov 08 13:58:10 thank you! **** BEGIN LOGGING AT Thu Nov 08 14:02:16 2018 Nov 08 14:23:10 ignisf: o/ Nov 08 14:23:13 long time no see :) Nov 08 14:27:45 morning Nov 08 14:31:25 stintel, \o Nov 08 15:56:19 whasn't there some make flag or var that could help update PKG_HASH? Nov 08 15:56:43 make package/something/check FIXUP=1 Nov 08 15:57:03 might need PKG_HASH=skip too, dunno exactly Nov 08 15:57:14 I tried PKG_HASH=fixme butit just said, "no recognised hash" Nov 08 15:57:22 needs to be skip Nov 08 15:58:20 but I think the PKG_HASH=skip is only needed for make package/blah/download Nov 08 15:58:32 hrm, skip just actually skipped Nov 08 15:58:56 * karlp goes backto "leave the old hash, rebuild, let it see what it thinks it should be" Nov 08 16:00:54 jow: buildbot behaviour is correct Nov 08 16:01:06 jow: they are properly coaslesced as you explained Nov 08 16:01:28 jow: I was looking at different targets with very similar names Nov 08 16:06:47 karlp: i think i leave mine blank, and do download Nov 08 16:09:54 the correct way to do it is: Nov 08 16:09:55 make package//download PKG_HASH=skip V=s Nov 08 16:10:02 make package//check FIXUP=1 V=s Nov 08 16:10:25 exactly what stintel said Nov 08 16:15:12 Hello people. Assuming that I provide a patch, how realistic would it be to expect "bridge vlan filtering" to be accepted as part of the default config? The existing ip-bridge package finds itself crippled for lack of in-kernel support and it seems like a pretty handy thing to have when considering OpenWRT as an all around networking swiss army knife. Nov 08 16:17:38 jow: would it be worth to get rid of mipsel-74kc? Nov 08 16:17:47 there are only two targets that use it Nov 08 16:25:21 FinboySlick: do you mean more than just flipping the sysctl? Nov 08 16:25:37 mangix: I'm always for reducing the amount of targets :) Nov 08 16:26:02 xback: I'll try to bring the new builders online tomorrow, or at least one of them Nov 08 16:26:05 lynxis: ping Nov 08 16:26:18 jow: pong Nov 08 16:27:13 lynxis: you planned to setup a ci pipeline on the new host(s), right? if so, whats the progress and do you need both of them? Nov 08 16:27:22 jow: I mean setting "CONFIG_BRIDGE_VLAN_FILTERING=y" in target/linux/generic/config-* Nov 08 16:27:53 FinboySlick: I think whenever we looked at it in the past, it had significant throughput impacts Nov 08 16:28:03 which was the reason for not enabling it by default Nov 08 16:28:42 jow: Really? It shouldn't affect throughput unless you actually use it. Nov 08 16:29:28 jow: only one. Nov 08 16:29:34 jow: It's not like the netfilter hook. Nov 08 16:30:22 jow: This is to make the bridge 'vlan aware' essentially like a managed switch (I want vlan x tagged on this port member of the bridge, etc.) Nov 08 16:31:01 huh intersting Nov 08 16:31:16 I'm pretty sure it gets bypassed altogether unless you specifically enable it on a bridge port. Nov 08 16:31:33 arch PKGBUILDs reference patches directly using gitweb Nov 08 16:31:56 FinboySlick: ok, then I might have misremembered. If you make an rfc patch with iperf before/after and kernel size comparison before/after and the impact is not too severe, than it might get accepted Nov 08 16:31:58 or cgit, w/e Nov 08 16:32:12 its living on the bleeding edge Nov 08 16:33:38 FinboySlick: you also need to make somewhat sure that it does not affect existing usecases, not sure how it interacts with swconfig etc. Nov 08 16:34:01 or 4addr AP_VLAN fivs Nov 08 16:34:04 *vifs Nov 08 16:43:31 jow: That's fair but I don't see how it would unless you actually use it. When actually used on a bridge, it creates a vlan bitmap per bridge port. If raw 802.1q frames come into one of those ports, they get forwarded or not according to the bitmap with optional tagging/untagging of a native vlan. Nov 08 16:44:18 it does do extra processing even without specifically configuring ports Nov 08 16:45:48 mangix: wasn't mips 74kc only fairly recently added? because they wanted more perf optimizations than they got with mips24k? Nov 08 16:46:15 define recent. It's been there as long as I can remember Nov 08 16:46:48 git history says 2014 Nov 08 16:46:56 jwh: Oh? Beyond checking if the bridge should care about vlans? Nov 08 16:47:03 hrm, I thought there had been more recent subtargets. Nov 08 16:47:12 was there some other target that got split out of 24k? Nov 08 16:48:38 karlp: mips*el*74k Nov 08 16:49:12 that's what mangix is saying has been there since 2014? Nov 08 16:49:24 but if there's allegedly no difference in generated code between mips74kc and mips24kc, then I'd assume there isn Nov 08 16:49:35 't one either between mipsel74kc and mipsel24kc Nov 08 16:50:47 It's similar to the ar71xx or ath79 situation. It uses mips24kc even though the newer devices support 74kc. The compiled code is not identical but is compatible. Nov 08 16:52:29 yes I recall Nov 08 16:54:46 it's 34kc and 24kc that's treated identically by GCC Nov 08 16:54:58 stintel: and 1004kc Nov 08 16:55:23 yes Nov 08 16:55:27 74kc is (supposed) to be different. Nov 08 16:55:34 indeed Nov 08 16:55:42 well, the hardware is Nov 08 16:55:44 see b962da4d929307a834850b72e42a44c2a00ed39e :) Nov 08 16:56:32 make package/foo/download PKG_HASH=skip ; make package/foo/check FIXUP=1 Nov 08 16:56:33 off the top of my head, 74kc has double the d-cache or something Nov 08 16:59:40 FinboySlick: even without configuring it, it still has to do vlan processing Nov 08 17:00:07 as frames still get tagged internally, sort of Nov 08 17:00:31 in a similar manner to real switches Nov 08 17:00:44 vaguely remembers that the instruction pipeline is longer (double?) on 74 Nov 08 17:04:28 (10)74k also supports the dsp2 ASE, while 24k/34k only support dsp1 ASE Nov 08 17:05:48 so code compiled for 74k might not run on 24k/34k Nov 08 17:12:50 hrm, what sorts of things trigger ntp to check again? I have no network on boot, and plug in network afterwards, and just wondering how long to wait for an event? Nov 08 17:12:59 KanjiMonster: oddly enough, some 64kc devices don't support dsp1 Nov 08 17:13:04 *74 Nov 08 17:13:59 ldir: any opinion on https://github.com/openwrt/packages/pull/7336 ? Nov 08 17:14:58 my opinion is that it's beyond my ability, certainly at the moment. Nov 08 17:16:20 ok Nov 08 17:17:02 I have also found the openssl documentation regarding api changes to be as opaque as openssl! Nov 08 17:17:49 nbd: Resets now succeed occasionally, but it still ends up dead after a few seconds of heavy traffic Nov 08 17:18:30 ldir: I changed the patch from my own random hacks to backporting upstream patches Nov 08 17:18:39 Monkeh: only with wds, or regular traffic as well? Nov 08 17:19:08 AFAICT packages that support 1.1.1 say that anything older needs to support the really deprecated 0.9.8 api, so generally get confused by 1.0.2 and 'no deprecated api' Nov 08 17:19:52 that makes no sense given that older than 1.0.2 is EOL Nov 08 17:20:45 I'm afraid I can't give a sense/no sense opinion on the basis I don't understand openssl..... and neither do the authors of openssl documentation. Nov 08 17:21:57 hrm, debian 7 uses openssl 0.9.8. That's EOL too Nov 08 17:22:24 nbd: I don't recall ever reproducing without WDS, but I'll give it a run through again now Nov 08 17:22:54 ldir: what makes you say that? Nov 08 17:23:19 Monkeh: please show me the output of cat /sys/kernel/debug/ieee80211/phy*/mt76/reset Nov 08 17:24:01 nbd: From the last run: TX hang: 4 Nov 08 17:24:01 TX DMA busy stuck: 0 Nov 08 17:24:01 RX DMA busy stuck: 0 Nov 08 17:24:01 Beacon stuck: 0 Nov 08 17:24:01 RX PSE busy stuck: 2 Nov 08 17:24:02 MCU hang: 63 Nov 08 17:24:23 MCU hang just climbs until it stops spamming timeouts. Nov 08 17:29:17 nbd: Normally takes 2-10s to trigger with WDS, three minutes in now without and no issues, no resets recorded Nov 08 17:35:49 mangix: if I'm honest it's frustration leading to anger at myself for not understanding - I do feel that there should be an openssl porting/migration guide somewhere. Nov 08 17:36:46 I'd like to see znc tweaked so that it can compile properly on 1.0.2 without deprecated APIs enabled. Nov 08 17:37:23 I've had a go, but the more I look at odd snippets of info courtesy mr google, the more I think I've done it wrong. Nov 08 17:42:56 ldir: I'll have a look at it Nov 08 17:47:25 mangix: have a look at https://github.com/ldir-EDB0/packages/commit/e65b608214a05c07678a9d917336da97ca4d96f7 the configure flag thing is right, but the disabling of the openssl version check is wrong, 'cos there's different implementations of the threading stuff between 0.9.8 and 1.0.2 and 1.1.1 with/without deprecated APIs enabled. so znc would wrok if we bumped ssl to 1.1.1 but it doesn't work on 1.0.2 with no_deprecated_api Nov 08 18:11:08 From a quick look, it just requires a similar patch to all the ones I've been submitting recently Nov 08 18:11:54 waiting on the toolchain to compile Nov 08 18:58:19 nbd: ping Nov 08 19:07:43 nbd: i tried to compile mt76 2018-11-08 on 18.06 but it breaks, maybe because of the older wireless stack? log is here: https://thepasteb.in/p/P1hrcjKk8LO7gIX Nov 08 19:10:41 ldir: https://github.com/openwrt/packages/pull/7356 Nov 08 19:26:07 mangix: looks good, except I see configure: WARNING: unrecognized options: --disable-nls, --enable-ssl. I had tweak in mine to change --enable-ssl to --enable-openssl Nov 08 19:26:34 I'll fix that up and merge :-) Nov 08 19:27:37 ah weird Nov 08 19:30:08 yes, I don't know by what magic it works out ssl is available anyway but it does - also without the correct flag if openssl isn't in a sane state it'll just compile without ssl - with the correct flags it barfs if openssl isn't ok Nov 08 19:41:46 mangix: ok I did the fixup & push - close your PR unless I've missed something Nov 08 19:56:33 ldir: lovely Nov 08 19:56:56 * mangix discovered people can delete their github comments. how pathetic. Nov 08 20:49:28 on a fast CPU system, at least, I see 175Mbps one direction, 95Mbps the other, UDP throughput, with realtek USB wifi NIC and out-of-tree driver Nov 08 20:49:37 better than I expected! Nov 08 20:56:30 greearb_: what card/adapter are you trying? Nov 08 20:57:33 greearb_: also, is that on OpenWRT? I was looking for a good performance USB card today Nov 08 20:58:58 not on openwrt yet, was debugging on easier-to-debug platform Nov 08 20:59:40 I'm using the comfast 912-ac currently Nov 08 21:00:14 the driver on github needs a bit of love, I posted some patches in bug reports to fix compile on openwrt, but loading on x86 system I see a lockdep splat, so it needs more help. Nov 08 21:03:51 from a purely functional point of view, the realtek drivers often work rather well - just never look into the source, and don't ever upgrade your kernel to a newer minor version again Nov 08 21:05:19 also don't ever think about putting them into AP mode, otherwise you'd be looking at a forked hostapd 0.4 variant... Nov 08 21:07:42 fortunately I'm using station mode Nov 08 21:08:17 here is git tree with openwrt help: https://github.com/greearb/rtl8812AU_8821AU_linux Nov 08 21:08:23 afk Nov 08 21:09:15 I'm compiling it against my 4.16-ct kernel, btw, and neo2 platform for openwrt with 4.16-ct kernel backports on 4.14 base openwrt kernel Nov 08 21:09:53 long time ago, I hoped for rtl8192du support (at least for staging) - sadly that didn't happen (I managed to slash the driver size in half by removing an initial batch of cruft, but there's still heaps to do) Nov 08 21:19:47 <_lore_> luaraneda: with mt76 I can get ~ 250/300M on i5 cpu Nov 08 21:20:24 <_lore_> with a mt76x2u usb dongle Nov 08 21:21:57 nice Nov 08 21:43:06 pkgadd, interested in 8812AU driver bundled into OpenWRT? I could probably accomplish that w/out too much trouble Nov 08 21:44:32 greearb_: I don't have any 8812AU device (just rtl8188su, rtl8192su (both covered by r8712u) and rtl8192du (out of tree driver)) Nov 08 21:44:57 I mean would you think a patch that added support to openwrt would be welcomed? Nov 08 21:45:14 why not? Nov 08 21:45:22 I've no interest in fighting to get it into upstream kernel, btw Nov 08 21:45:53 wouldn't that depend on the state of the driver itself? Nov 08 21:46:23 Borromini: works(TM), but don't look, don't move, don't expect anything but STA Nov 08 21:46:58 and if the compile logic is already handled, then maybe bug fixes will trickle into the driver...one less hurdle Nov 08 21:47:34 Is that the driver using wireless extensions? I remember reading something about that the past year Nov 08 21:48:15 pkgadd: ok. which would make it end up in openwrt/packages then i suppose? Nov 08 21:48:37 luaraneda: yes, those drivers are using a private kernel 2.16-era ieee80211softmac stack, but realtek is one of the cool kids to add a cfg80211 emulation layer on top (my eyes...) Nov 08 21:48:59 :D Nov 08 21:49:04 nbd: xback May I direct your attention to https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=6398f131dc8640e3fde4126c77190c965423a70a This really needs to be done by an adult :-) Nov 08 21:49:56 Borromini: it 'works' well enough for "iw dev wlan%d scan" and maybe, if you're lucky, network-manager... Nov 08 21:50:20 :) Nov 08 21:51:11 the hardware isn't bad, but the drivers... Nov 08 21:51:48 but sharing is caring right, and that's what realtek does ;-) Nov 08 21:52:12 and too many variations of the hardware with different forks of a similar driver, using multiple abstraction layers for the different operating systems Nov 08 21:52:21 pkgadd (IRC): That means the driver is not upstreamable at the moment. If I remember correctly, only cfg80211 drivers are accepted upstream Nov 08 21:52:37 luaraneda: correct, only staging Nov 08 21:52:55 and chances for it to ever leave staging are minimal at best Nov 08 22:34:05 build #1094 of x86/legacy is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/x86%2Flegacy/builds/1094 Nov 08 22:34:27 hmm, my Build/Compile code is not being run, I see it rm the .build, and then touch .built_check Nov 08 23:36:05 anyone know of a way to tell in an OpenWRT Makefile if system is BIG or LITTLE endian? Nov 08 23:58:29 greearb_: I think that's defined by the toolchain. Not sure if there's a CONFIG or flag that you can test Nov 08 23:58:56 think I found a thing gcc defines internally Nov 09 00:00:55 Nice Nov 09 00:02:03 i'm going thru git log ./target/linux/ipq40xx/files-4.14/arch/arm/boot/dts Nov 09 00:03:04 wanted to stop here and ask if anyones workin in this section Nov 09 00:03:22 git log won't get you very far in that regard, as the patch set was copied in separate commits from 4.9 to 4.14 and was broken out of ipq806x before Nov 09 00:10:15 i'm building for all or generic/default.. for a *gulp* mtik device Nov 09 00:12:55 ...freaking mistook device as hap ac-lite (ar71xx) and not hapac2 (ipq40xx) Nov 09 00:13:10 ;_; Nov 09 00:17:11 I still can't parse any actual question from that; obviously there is no MikroTik RouterBOARD hAP ac 2 (RBD52G-5HacD2HnD-TC) support in OpenWrt yet, so you'll have to start with porting it Nov 09 00:39:09 lovely Nov 09 00:39:21 all github releases don't work anymore Nov 09 00:40:03 hmm? Nov 09 00:41:43 example: https://github.com/rakshasa/rtorrent/releases/download/v0.9.7/rtorrent-0.9.7.tar.gz Nov 09 00:41:51 codeload works but the releases don't work Nov 09 00:41:59 gotta love that microsoft magic Nov 09 00:42:44 insane Nov 09 00:43:27 is that supposed to be broken? Nov 09 00:43:46 no Nov 09 00:43:48 oh Nov 09 00:44:06 coz that url downloads ok Nov 09 00:44:24 hmmmm? It doesn't for me Nov 09 00:44:35 DNS error Nov 09 00:44:57 [jwh@pyxis ~]$ curl -sL https://github.com/rakshasa/rtorrent/releases/download/v0.9.7/rtorrent-0.9.7.tar.gz | file - Nov 09 00:45:00 /dev/stdin: gzip compressed data, last modified: Thu Jun 7 04:25:31 2018, max compression, from Unix Nov 09 00:45:47 libnl3_4_0, libevent2, libusb, etc.. wont download/build Nov 09 00:45:49 ah, maybe broken cdn stuff, that isn't microsoft thats github it happens pretty often Nov 09 00:45:51 yeh, definitely a microsoft problem. Nov 09 00:46:04 /dev/stdin: empty Nov 09 00:46:06 gotta hate on them for being equally broken as they have been in the past though Nov 09 00:46:21 DNS server is set to 1.1.1.1 Nov 09 00:46:26 github don't need any help at partially breaking stuff for some people but not others Nov 09 00:46:31 mangix: curl --head ? Nov 09 00:46:50 /dev/stdin: ASCII text, with very long lines, with CRLF line terminators Nov 09 00:47:01 oh interesting, what are the contents? Nov 09 00:47:35 https://gist.github.com/neheb/2de5a461f1b4ac123d741b51076c38ce Nov 09 00:47:51 It's the redirect that's broken Nov 09 00:48:03 the URL at the location Nov 09 00:48:19 oh that isn't a hideous url at all :D Nov 09 00:49:03 I get redirected to the same url and it works Nov 09 00:49:14 well, the key differs of course Nov 09 00:49:25 build #195 of at91/sama5d2 is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/195 blamelist: Koen Vandeputte , Felix Fietkau , Hans Dedecker , Daniel Golle , Jo-Philipp Wich Nov 09 00:49:32 perhaps local/regional stuff is broken (ha, aws etc) Nov 09 00:51:12 ERR_NAME_NOT_RESOLVED says DNS error Nov 09 00:52:56 oh yea, works. Nov 09 00:53:22 github-production-release-asset-2e65be.s3.amazonaws.com’s server IP address could not be found. Nov 09 00:54:57 cloudflare suck? :D Nov 09 00:55:43 maybe worth doing a dig +trace, see where its broken Nov 09 00:56:03 coz that should be a cname Nov 09 00:56:24 phone over lte works Nov 09 00:56:26 lovely... Nov 09 00:56:46 volte? Nov 09 00:56:55 erm data Nov 09 00:57:00 oh Nov 09 02:50:00 nbd: Managed to get a couple of TX hangs and MCU hangs out of an hour long iperf session without WDS, both recovered. Also, at some point while I was away and it was idle, it hung and somehow took the kernel with it: https://gist.github.com/eamaclean/b8354f70e1f56f03ea274d990a00dda7 **** ENDING LOGGING AT Fri Nov 09 02:59:58 2018