**** BEGIN LOGGING AT Wed Dec 18 03:00:35 2019
Dec 18 07:22:44 <Tapper> luci-app-https-dns-proxy has a dependency  on https-dns-proxy witch does not exist
Dec 18 09:09:41 <stintel> any chance this is supportable: http://en.techinfodepot.shoutwiki.com/wiki/Huawei_AP7060DN ? IPQ8074 QCN5154 QCN5124
Dec 18 09:10:06 <stintel> it's pricy but dayum I like dat specs
Dec 18 09:11:03 <user747> any one tried flashing a g-wifi (IPQ4019) mesh puck before ?
Dec 18 09:14:01 <owrt-snap-builds> build #227 of brcm63xx/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fgeneric/builds/227  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sungbo Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Kevin Darbyshire-Bryant <ldir@darbyshire-
Dec 18 09:14:01 <owrt-snap-builds> bryant.me.uk>, Birger Koblitz <mail@birger-koblitz.de>, Imran Khan <gururug@gmail.com>
Dec 18 09:16:09 <owrt-snap-builds> build #228 of oxnas/ox820 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/228  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sungbo Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Kevin Darbyshire-Bryant <ldir@darbyshire-
Dec 18 09:16:09 <owrt-snap-builds> bryant.me.uk>, Birger Koblitz <mail@birger-koblitz.de>, Imran Khan <gururug@gmail.com>
Dec 18 09:17:07 <owrt-snap-builds> build #225 of lantiq/ase is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/225  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sungbo Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Birger
Dec 18 09:17:07 <owrt-snap-builds> Koblitz <mail@birger-koblitz.de>, Imran Khan <gururug@gmail.com>
Dec 18 09:55:29 <ldir> Tapper: agreed - the package in the package feed has changed name and the matching commit in luci hasn't yet been done... and now has conflicts
Dec 18 10:12:11 <ldir> oops wrong channel
Dec 18 10:16:44 <Pepe> Tapper:  This one https://github.com/openwrt/luci/pull/3402 should solve it
Dec 18 10:42:43 <jow_> why is that DNS-over-whatever-crap such a tedious chrun all the time?
Dec 18 10:42:54 <jow_> *churn
Dec 18 10:43:04 <owrt-snap-builds> build #221 of arc770/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/221  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sungbo Eo <mans0n@gorani.run>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Kevin Darbyshire-Bryant <ldir@darbyshire-
Dec 18 10:43:04 <owrt-snap-builds> bryant.me.uk>, Birger Koblitz <mail@birger-koblitz.de>, Imran Khan <gururug@gmail.com>
Dec 18 10:49:09 <PaulFertser> jow_: apparently people want to hide their DNS requests from their ISP. But then the ISP still sees all the connections and can make RDNS requests for the addresses...
Dec 18 10:49:26 <jow_> use a vpn
Dec 18 10:54:06 <PaulFertser> Yes, I can't understand it either. If ISP is hostile, you have to encrypt all the traffic and route it via an external server anyway.
Dec 18 10:54:29 <PaulFertser> Tapper: what's your usecase, what's the threat model that makes DoT meaningful?
Dec 18 10:56:10 <zorun> it can avoid some forms of mass surveillance
Dec 18 10:56:19 <zorun> it makes it more difficult / costly to do
Dec 18 10:57:14 <PaulFertser> zorun: as soon as it becomes common, ISPs will start doing rdns lookups, doesn't sound costly at all.
Dec 18 10:58:02 <zorun> it doesn't give you the same level of information
Dec 18 10:58:38 <zorun> and don't forget DNS MiTM for censorship, which is extremely easy to do
Dec 18 10:58:55 <zorun> MiTM connection is always possible but harder
Dec 18 10:59:01 <PaulFertser> Well, yes, but it doesn't seem to be enough of a difference, and not enough for such an obvious layering violation.
Dec 18 11:00:03 <PaulFertser> Those willing to do censorship will have it working one (stupid, unreliable, annoying) way or the other. I know, I live in russia.
Dec 18 11:04:45 <ldir> jow_: because it's an evolving thing/standard
Dec 18 11:06:20 <ldir> I don't like the idea of my ISP doing DPI on my dns requests
Dec 18 11:06:21 <jow_> ldir: yeah I figured. One could also call it "immature". I mean its not some random latest javascript framework fad but DNS
Dec 18 11:09:02 <ldir> I like the idea that DNS over foo makes censorship/monitoring a little less 'low hanging fruit'
Dec 18 11:09:16 <PaulFertser> ldir: then it'll do it for your non-eSNI requests. Doesn't seem to be much difference really. With eSNI widely deployed and if you mostly use services behind popular load balancing, probably that will make some sense.
Dec 18 11:10:05 <ldir> Whether I trust google/cloudfare etc etc any more is an interesting/uncomfortable question.
Dec 18 11:10:11 <jow_> :)
Dec 18 11:10:38 <jow_> or whether your particular view of 1.1.1.1 is cloudflare in the first place
Dec 18 11:11:36 <jow_> I mena iwth having a "Deutsche_Telekom_Root_CA_2.pem" in the defualt cert store and 1.1.1.1 bein an anycast IP, I doubt that it would be that hard for a state actor to simply divert requests to it somewhere else
Dec 18 11:12:33 <jow_> so DNS-over-* establishes some form of transport security, but I guess without cert pinning and dnssec inside, no integrity or authenticity guarantees
Dec 18 11:14:08 <jow_> but maybe I misunderstood it
Dec 18 11:15:16 <nbd> i guess the idea is that bogus ca-signed certificates for MITM would be caught by browser logging and verifying with certificate transparency
Dec 18 11:15:50 <jow_> unless its moved to headless resolver running on some embedded appliance
Dec 18 11:16:29 <PaulFertser> Integrating DNS resolving in a web browser is just nuts.
Dec 18 11:19:25 <xback> 'lo all
Dec 18 11:19:39 <jow_> hi xback
Dec 18 11:21:14 <xback> srry for the absence, the company moved so I spend a few days lifting boxes and servers :-)
Dec 18 11:21:18 <xback> currently bumping ..
Dec 18 11:22:47 <zorun> agreed, DoH in browsers is a step in the wrong direction...
Dec 18 11:23:24 <stintel> xback: no apologie needed, wb :)
Dec 18 11:23:27 <zorun> DoT in the home router could make sense
Dec 18 11:23:37 <zorun> but certificate pinning is hard
Dec 18 12:11:11 <pkgadd_> stintel: blogıc seems to have been working on ipq807x, ath11k will be part of kernel v5.6 - so I'm carefully optimistic
Dec 18 12:11:45 <stintel> pkgadd_: cool
Dec 18 12:12:02 <pkgadd_> and the SOC is pretty cool
Dec 18 12:12:37 <stintel> this huawei AP is really cool, has PoE and console port, only the prices I find online ... ~1kEUR
Dec 18 12:12:58 <pkgadd_> the consumer routers without PoE are around half of that
Dec 18 12:13:01 <stintel> still waiting for prices for a 10gigE PoE switch and this ap from my reseller
Dec 18 12:13:20 <stintel> the 8x8 might be overkill :P
Dec 18 12:13:40 <pkgadd_> don't worry, apart from antenna size it's no problem ;)
Dec 18 12:15:26 <pkgadd_> if RAM size is listed correctly for that Huawei AP7060DN, I'd be slightly worried though
Dec 18 12:15:40 <pkgadd_> 256 MB RAM sounds very, very low
Dec 18 12:19:35 <pkgadd_> the other ipq807x based devices tend to come with 1 GB RAM
Dec 18 13:21:10 <ldir> xback: welcome back!
Dec 18 15:06:59 <stintel> karlp: do you have experience with random timeouts of all clients on a mosquitto broker, which solves itself after random time?
Dec 18 15:21:02 <stintel> https://pocket.popcorncomputer.com/
Dec 18 16:21:52 <greearb_> anyone know what 'SAR' means regarding wifi tx power?
Dec 18 16:33:24 <zorun> probably the Specific Absorption Rate, in many countries there is a legal limit on it but it's mostly for mobile phones
Dec 18 16:35:17 <xback> blocktrron: fyi, I bumped 5.4 to 5.4.5 in my staging.  It's inclosed within the introduction patch for 5.4
Dec 18 16:36:47 <xback> fyi, new bumps pushed to staging
Dec 18 16:43:11 <greearb_> zoron: thanks
Dec 18 16:43:17 <stintel> 5.4.5? geez I built 5.4.4 last night, didn't even have the chance to reboot
Dec 18 16:45:44 <stintel> I don't see any CVE references in the changelog but I suspect some might follow :P
Dec 18 16:48:49 <xback> I think I wont get 5.4 in a pretty state before newyear,  tomorrow is my last day at the office for 2k19 :)
Dec 18 16:50:40 <stintel> xback: cool. enjoy holidays!
Dec 18 16:51:02 <xback> thnx :-)  likewise!
Dec 18 16:51:34 <stintel> unfortunately I'll be working most days until the 2020 arrives
Dec 18 16:52:18 <stintel> c'est la vie :)
Dec 18 19:18:41 <abenz_> stintel: huawei ap for OpenWrt dev? or use it with stock fw?
Dec 18 19:19:53 <abenz_> I dont understand why its very expensive, at that price, its reaching aruba and ruckus territory, and those come with more features from what I can tell
Dec 18 19:47:47 <MartB|Martin> Why is most of the flow offload stuff in openwrt still not mainlined? Are more recent patchsets available or did upstream move into a different direction?
Dec 18 20:49:47 <pkgadd> abenz: that's ipq8074 --> 802.11ax, which is still expensive in general
Dec 18 21:52:40 <stintel> abenz: well I would prefer to be able to run openwrt on it :)
Dec 18 22:03:08 <pkgadd> Looking the activity frenzy on ath11k patch submissions for net-next (so v5.6), it's looking quite positively. ipq8074 SOC support has been mainline for quite a while, but afaik there are missing bits an pieces (in mainline, code is there) in terms of wired networking and probably storage as well (and nss/ npu)
Dec 18 22:06:32 <pkgadd> but considering that ath10k really needs 256 MB RAM for stable operations (for two interfaces), I'd be slightly worried about 'just' that much for ath11k and ipq8074 - considering that it's a) 64 bit ARMv8, b) quad-core cortex a53 @2.2-2.4 GHz and c) probably some additional RAM requirements for the 802.11ax hardware
Dec 18 22:08:10 <pkgadd> mimo, more parallel chains
Dec 19 00:18:57 <Goerge255> Where in the Build System are the Kernel Headers, which have been patched by OpenWRT patches ?
Dec 19 00:20:54 <Goerge255> openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-armvirt_32/linux-4.14.158/include
Dec 19 00:20:58 <Goerge255> or...
Dec 19 00:21:01 <Goerge255> openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.3.0_musl_eabi/linux-dev
**** ENDING LOGGING AT Thu Dec 19 03:00:12 2019