**** BEGIN LOGGING AT Thu Aug 16 03:00:00 2018 Aug 16 03:18:23 2.5 GBit/s and 5 GBit/s aren't that far away, for full 10 GBit/s you'd probably have to look at the top-end ARMv8/ ARM64 server boards Aug 16 03:19:56 e.g. https://www.cnx-software.com/2014/12/04/applied-micro-xc-1-server-development-board-mustang-is-now-available-to-developers-for-895/ Aug 16 03:21:27 or this https://www.cnx-software.com/2015/03/27/gigabyte-mp30-ar0-is-an-arm-server-motherboard-powered-by-applied-micro-x-gene-1-soc/ might be actually available Aug 16 03:34:02 i see Aug 16 03:34:06 so not here yet Aug 16 03:34:23 or the NXP layerscape stuff https://www.cnx-software.com/2016/03/24/nxp-introduces-qoriq-ls1046a-quad-cortex-a72-communication-processor-with-10-gbe-sata-3-0-pcie-3-0-etc/ https://www.cnx-software.com/2018/05/03/nxp-qoriq-layerscape-lx2160a-is-a-16-core-arm-cortex-a72-communication-processor-with-100-gbit-s-ethernet/ Aug 16 03:34:48 https://www.cnx-software.com/2017/04/24/solidrun-macchiatobin-mini-itx-networking-board-is-now-available-for-349-and-up/ that might also count as available Aug 16 05:12:29 mangix: Search for QCA´s ipq8078, some devices are already announced Aug 16 05:12:58 https://www.qualcomm.com/news/releases/2018/06/26/qualcomm-and-new-h3c-ship-80211ax-enterprise-access-point Aug 16 05:13:12 wikidevi lists a few iirc Aug 16 05:13:28 It has 802.11ax too, but I imagine that would be a while for OpenWRT support Aug 16 05:14:03 mangix: https://www.solid-run.com/marvell-armada-family/macchiatobin/ 2x10GE, 1x2.5GE, 1GE. Marvell 8040 SoC. Aug 16 05:17:09 I haven't read the marvell and NXP SoCs, but QCA's has "network processors" to be able to route at ~10 Gbps, allegedly xD Aug 16 05:17:47 Marvell doesn't, they just do it in CPU. I haven't tested 8040 (yet), but the Marvell Armada 385 has plenty of CPU performance to route 1GE even with smaller packet sizes. Aug 16 05:18:41 mangix: there is already 18.06 build target for the macciatobin. Aug 16 06:07:29 trying to build pyzmq on openwrt , any pointers Aug 16 09:24:28 Guest44777: are you having any specific problems? Aug 16 09:30:01 here's a pointer: (void *)0x9b34bb7a Aug 16 09:32:45 jow: is that a valid pointer ? Aug 16 09:32:51 and will it work on a 64bit machine Aug 16 09:35:42 feature creep :) that wasn't in the original request! Aug 16 09:36:02 oh true Aug 16 11:11:46 i'm updating brcmfmac in the lede-17.01 Aug 16 11:12:00 I tested it with BCM43602 and BCM4366 (4366b1) Aug 16 11:12:13 if anyone is willing to test it with SDIO device, that'd be great Aug 16 11:25:15 dedeckeh: ping Aug 16 11:41:53 rmilecki: ping, do you received my mail? Aug 16 11:45:17 DonkeyHotei: pong Aug 16 11:46:58 dedeckeh: somebody in the household apparently introduced an IoT device and proceeded to manually change its hostname to include a space, which its dhcp client apparently passes straight to odhcpd, which somehow thinks that's valid, thus breaking unbound's scripts Aug 16 11:47:05 18.06 branch Aug 16 11:48:43 luaraneda: marvell has hardware support too AFAIK. Aug 16 11:48:52 DonkeyHotei:Via DHCPv6 or DHCPv4 ? Aug 16 11:48:59 v4 at least Aug 16 11:49:29 DonKeyHoeti:you're using odhcpd as DHCPv4 server ? Aug 16 11:50:01 yes, both v4 and v6, with it accepting the space for both Aug 16 11:52:00 DonKeyHotei:and unbound is failing if the hostname has a space? Aug 16 11:52:28 well, unbound-control is Aug 16 11:53:41 the support scripts assume the hostname will not contain a space, so it's parsed as a delimiter Aug 16 11:54:05 so you would like odhcpd to refuse such hostnames ? Aug 16 11:54:21 either ignore them or replace the space Aug 16 11:55:04 i'm pretty sure the dhcp spec allows only certain chars Aug 16 11:55:35 lack of validation is likely to break other things too Aug 16 11:56:13 I'm worried about the possible breakage it will cause Aug 16 11:56:13 this is CVE-worthy Aug 16 11:57:11 in existing setups Aug 16 11:57:59 odhcpd's own leases file is space-delimited Aug 16 11:59:28 shouldn't be spaces in dhcp hostnames anyway, sensible clients won't send thm Aug 16 11:59:31 them Aug 16 12:00:28 assuming sensible clients is a security hole Aug 16 12:00:48 yup Aug 16 12:01:11 but they're not rfc compliant by sending spaces anyway, so should definitely emove it from the request Aug 16 12:01:16 or don't respond at all Aug 16 12:01:28 remove* Aug 16 12:01:43 that's indeed not supported by rfc921 but in reality ... Aug 16 12:01:49 and not just spaces Aug 16 12:02:04 there are pretty strict restictions on characters Aug 16 12:02:13 largely follows the same as (non-idn) domains Aug 16 12:02:34 those restrictions should be enforced in any dhcp server Aug 16 12:02:43 anyway just checked dnsmasq which refused hostnames with white spaces Aug 16 12:02:44 so [a-zA-Z0-9-_] Aug 16 12:02:54 will take that up in odhcpd Aug 16 12:02:59 ty Aug 16 12:03:04 :D Aug 16 12:03:10 good spot DonkeyHotei Aug 16 12:03:50 dedeckeh: any fix needs to get into 18.06.1, which is supposed to be tagged *today* Aug 16 12:04:47 won't make it today; need to finish real work first Aug 16 12:04:59 sorry about that Aug 16 12:05:08 jwh: it's not [a-zA-Z0-9-_], because "-" is allowed Aug 16 12:05:21 oh, it's in there Aug 16 12:05:23 yeah that should have been \- Aug 16 12:05:27 I guess Aug 16 12:05:45 dedeckeh: hopefully the tag can be delayed Aug 16 12:06:10 jow: ^ Aug 16 12:13:59 DonkeyHotei: shouldn't unbound simply quote its args? Aug 16 12:14:04 I'm failing to see the issue Aug 16 12:14:32 args are not the issue Aug 16 12:14:55 stuff gets read and written to files as records Aug 16 12:16:38 hostnames containing chars other than -, _, 0-9, or alpha are not supposed to be valid, and dnsmasq correctly rejects them Aug 16 12:17:02 but odhcpd apparently lacks the input validation Aug 16 12:18:08 I understand that, but odhcpd isn't using the hostname, merely writing it out as-is, so I fail to see the CVE potential Aug 16 12:18:20 its the users of the lease files that need to protect against untrusted input Aug 16 12:18:27 in this case its apparently ubound-control Aug 16 12:18:59 so odhcpd does not need to read its own leases? Aug 16 12:19:36 it does, but does it crash / segfault / stack smash while doing so? Aug 16 12:20:45 that will depend on input validation, and if it lacks that, all bets are off Aug 16 12:21:42 seems odhcpd does not even read its statefile Aug 16 12:22:06 the only open() on config.dhcp_statefile happens with O_CREAT | O_WRONLY Aug 16 12:22:30 so why does it even have one? Aug 16 12:22:43 to expose information for dhcp leases Aug 16 12:23:59 i suppose it was an afterthought, unlike in dnsmasq Aug 16 12:25:03 probably doesn't matter that much as clients with existing leases, or those that have some persistent will ask for their current or previous address Aug 16 12:26:00 dhcp leases in owrt are persistent regardless Aug 16 12:26:24 even across sysupgrade -n Aug 16 12:26:25 yeah Aug 16 12:26:33 yeah but not due to statefiles Aug 16 12:26:33 hm? Aug 16 12:26:39 is that due to client id or something? Aug 16 12:26:53 thats due to dnsmasq PRNG seeded by the client mac Aug 16 12:26:57 ah Aug 16 12:26:59 yes Aug 16 12:27:12 this means the same "random" pool ip is allocated for the same mac (preferably, if no collission) Aug 16 12:27:22 for ipv6, it's the system id Aug 16 12:27:32 dnsmasq will also use client id Aug 16 12:27:49 which sucks as it will unconditionally ACK that address even if its in use Aug 16 12:28:07 that bit me when I was cloning containers Aug 16 12:28:37 different mac address but networkd generates the client id from the machine-id which was the same :D Aug 16 12:30:59 so in any case it seems unbound-control should validate whatever it is reading Aug 16 12:31:31 is that really the only thing that reads it? Aug 16 12:31:49 by default the only thing reading it is a) dnsamsq and b) luci Aug 16 12:31:54 both validate each line read from it Aug 16 12:33:00 hmm Aug 16 12:33:20 the leaste state file was designed to be hosts(5) compatible Aug 16 12:33:38 the actual info is "hidden" in comments, leases that have hostnames are written as additional hosts(5) compatible line Aug 16 12:33:50 I see two potential problems: Aug 16 12:34:11 hostname containing \n, thn the comment will be broken resulting in a broken hosts(5) record on the next line Aug 16 12:34:30 hostname containing " ", then the hosts(5) line will containing multiple hostnames for an ip Aug 16 12:34:33 which is legal btw Aug 16 12:34:42 so unbound-control shouldn't even choke on it Aug 16 12:35:23 so it may be trying to parse the comment Aug 16 12:35:55 excerpt from my default Debian /etc/hosts: Aug 16 12:35:56 "::1 localhost ip6-localhost ip6-loopback" Aug 16 12:36:27 "192.168.1.123 foo bar" should associate both "foo" and "bar" with 192.168.1.123 Aug 16 12:38:13 in that case, wouldn't the (not valid) dhcp hostname of "my computer" mean "1.2.3.4 my computer" ends up there? Aug 16 12:38:22 correct Aug 16 12:38:36 which might be semantically incorrect but not syntactically Aug 16 12:38:44 mmm, I' suggest that wuldn't be the expected behaviour Aug 16 12:38:54 true, but still not cve worthy behaviour Aug 16 12:38:57 jwh: the quesiton is whether this is "CVE level" Aug 16 12:39:00 but i shouldn't make it that far anyway as there are no spaces in hostnames Aug 16 12:39:03 oh Aug 16 12:39:03 no Aug 16 12:39:25 I am trying to assert if this is a "drop your pens and stop everything now!" issue or not Aug 16 12:39:36 jow:don't think so Aug 16 12:39:57 and so far it seems to be that some consumer of /tmp/hosts/odhcpd was a little bit too optimistic about the input format Aug 16 12:39:58 but it depends, if it doesn't do any validation of the name, could you craft something that can cause consumers of the lease file to exec code? Aug 16 12:40:04 or commands Aug 16 12:40:18 jwh: yes, but unbound is neither enabled by default nor maintained by us Aug 16 12:40:22 I agree the hostname validation can be improved but it's not a show stopper for me Aug 16 12:40:26 trusay Aug 16 12:41:46 question is also what should happen with invalid names Aug 16 12:42:10 in the interest of preserving information I'd probably write them out in some encoded form, like broken\x20hostname Aug 16 12:43:05 so you can still display the info in luci ? Aug 16 12:43:32 *imho* silently throwing away invalid hostnames is way more unintuitive than exposing them Aug 16 12:43:37 does hosts(5) allow comments at the end of the line? Aug 16 12:43:48 dnsmasq does not do that, so it would be weird to have it written for ipv6 and not written for ipv4 by default Aug 16 12:43:56 jwh: yes Aug 16 12:44:06 could always just do # broken hostname Aug 16 12:44:09 or somethign Aug 16 12:44:40 with the original in, which would maybe be useful Aug 16 12:45:00 odhcpd already writes a comment Aug 16 12:45:06 ah Aug 16 12:45:24 in any case it seems unbound simply needs to be fixed to validate its input Aug 16 12:45:40 which, honestly, is something I would have expected from such security nerd software Aug 16 12:46:18 DonkeyHotei: JOOI, how come you're not using dnsmasq for ipv6 too? Aug 16 12:46:29 the question becomes whether any ill can occur from a hosts line of "192.168.1.2 foo bar.lan foo bar" Aug 16 12:46:51 jwh: you know odhcpd is the default for ipv6, right? Aug 16 12:46:54 yes Aug 16 12:47:09 the question is if it is expected behaviour for the system resolver to crahs and born when there's garbage in /etc/hosts Aug 16 12:47:17 *crash and burn Aug 16 12:48:05 what exactly is the problem with unbound anyway? Does it refuse to start up? Aug 16 12:48:17 garbage in /etc/hosts does seem to cause unexpected behavior Aug 16 12:48:33 unbound starts up, but unbound-control does not Aug 16 12:50:37 i previously had to do a pr for unbound because it did not start up when odhcpd was used, but this was iproute2's fault, not odhcpd's Aug 16 12:54:56 jow:ping Aug 16 12:59:39 heh, rrdtool added native lua bindings in 1.4, but added a hard glib requirement in 1.3. Aug 16 12:59:42 fantastic Aug 16 13:00:03 :( Aug 16 13:03:10 are there any real competitors? all the "modern" tsdb stuff is huge bigiron/bigdata stuff. Aug 16 13:05:39 depends what you're collecting really Aug 16 13:05:56 dedeckeh: pong Aug 16 13:05:58 theres all the hippy stuff with the webuis Aug 16 13:06:11 jwh: just talking about the datastore Aug 16 13:06:14 oh Aug 16 13:06:38 in that case dunno, never found an alternative Aug 16 13:09:15 * karlp builds glib and sees how big it is anyway. Aug 16 13:10:06 does odhcpd use the hostname for anything other than the statefile? Aug 16 13:10:16 DonkeyHotei: no Aug 16 13:11:50 i'm assuming luci reads only the actual hosts lines and not the comments Aug 16 13:13:35 DonkeyHotei:hostnames are exported so dnsmasq knows them for resolving and for luci Aug 16 13:18:38 after enable dnsmasq for local network-resolve on wrieguard-vpn dns-resolvimg is gone. Aug 16 13:20:25 sorry. my english ist not good Aug 16 13:29:20 hsp: you want to allow dns on wireguard so you redirect all traffic from client (and avoid dns leak) ? Aug 16 13:30:40 ?? Aug 16 13:33:11 two options to get dnsmasq to respond to dns over wireguard: Aug 16 13:33:33 1. disable option localservice, or Aug 16 13:33:46 2. manually put the interfaces you want dnsmasq to respond to, in my case: Aug 16 13:34:07 list interface 'lan' Aug 16 13:34:07 list interface 'wg0' Aug 16 13:34:07 list interface 'loopback Aug 16 13:34:16 in /etc/config/dhcp Aug 16 13:34:21 second option is better I think Aug 16 13:34:38 if thats not what you're asking about, then lost in translation my friend! Good luck with your probs Aug 16 13:40:50 autowinning again: error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 Aug 16 13:41:01 ??which section in dhcp abenz Aug 16 13:41:10 ups Aug 16 13:41:10 karlp: lol Aug 16 13:42:05 hsp: under config dnsmasq (top of file) Aug 16 13:42:11 told rrdtool to disable perl, decided it had found staging_dir_host/bin/perl so it turned it back on again. Aug 16 13:42:14 thanks autowin Aug 16 13:42:14 i try Aug 16 13:42:29 when done restart dnsmasq and all should work Aug 16 13:42:30 karlp: gg Aug 16 13:43:18 abenz, ==> option list interface 'wg0' right? Aug 16 13:43:21 karlp: iirc there's a PKG_FIXUP for the gettext version mismatch Aug 16 13:43:39 hsp: no, just list Aug 16 13:43:46 I will show you an example Aug 16 13:44:03 jow: yeah, jsut found that one, was grepping the pagakges repo logs to see if anyone else had patched similar thigns :) Aug 16 13:44:57 hsp: https://paste.debian.net/1038151/ Aug 16 13:46:56 abenz, local dns-resovle not work, wan works Aug 16 13:51:54 mkresin: i received it, but didn't have time to focu on that yet, sorry Aug 16 13:53:23 rmilecki: no worries. as long as the mail doesn't made it into your spam folder, everything is fine Aug 16 13:55:10 hsp: is 'lan' the name of your network under /etc/config/lan ? Aug 16 13:55:26 paste your /etc/config/network and /etc/config/dhcp after removing sensitive information Aug 16 13:55:56 abenz, all good, typo, it works. many thanks Aug 16 13:57:14 np Aug 16 13:57:39 abenz, i have write 'kan' :) Aug 16 13:58:03 :) Aug 16 14:08:04 heh, rrdtool 1.0 ~ 150k. rrdtool 1.7 (with glib, but _no_ graphics) ~1.4MB Aug 16 14:08:16 there's more stuff there of course, but still, massive increase :) Aug 16 14:08:55 off topic: last chance to give your vote on whether to abolish or continue the practice of daylight saving time in the eu: https://ec.europa.eu/eusurvey/runner/2018-summertime-arrangements?surveylanguage=EN Aug 16 14:09:16 they've kept that quite Aug 16 14:09:20 quiet ffs Aug 16 14:09:36 well, it's just a survey, eu doesn't mndate times. Aug 16 14:10:40 they can suggest member states change them though Aug 16 14:10:52 or just force them, because EU Aug 16 14:11:23 oh boy, they are actually, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0084 Aug 16 14:11:39 heh Aug 16 14:11:50 to coordinate dst I believe Aug 16 14:11:53 * karlp is a fan of having people observe the day, not be tied rigidly to a number on a wall. Aug 16 14:12:24 sure, a flexible makes sense Aug 16 14:12:26 heh Aug 16 14:12:28 workday** Aug 16 14:12:41 just getting up when you want fixes all time problems Aug 16 14:12:43 :D Aug 16 14:12:47 yup. Aug 16 14:13:08 well, some people are early types, some are late types, but most people are somewhere in between Aug 16 14:13:33 if its light, its time to get up Aug 16 14:13:35 thus you could have a "core" time where most stuff happens Aug 16 14:14:08 if its dark, time to leave the office Aug 16 14:25:03 huaracheguarache, done :) Aug 16 14:25:26 I went for abolishing the switch and having perma summertime Aug 16 14:25:45 seems like a reasonable choice Aug 16 14:28:05 we have people here campagaining to push the clock in _both_ directions. Aug 16 14:29:30 ?! Aug 16 14:52:16 yeah, exactly. madness. Aug 16 14:54:42 hsp: https://www.shz.de/deutschland-welt/panorama/zeitumstellung-2017-biologe-fordert-abschaffung-id18181401.html Aug 16 14:56:28 huaracheguarache, already read this Aug 16 14:58:24 nice =) Aug 16 14:59:21 huaracheguarache, wireguard now works :) Aug 16 14:59:43 that's great! what did you have to tinker with to get it to work? Aug 16 15:02:16 huaracheguarache, look at 15:29 Aug 16 15:03:48 you just have to know Aug 16 15:38:18 philipp64: I think you need to restrict your perlver.mk include to ifneq ($(DUMP),1) Aug 16 15:39:22 philipp64: nevermind Aug 16 15:45:37 oh. Yet another side-channel attack against Intel CPUs Aug 16 18:53:39 jow: do your rpcd cahnges fix the problem described in this strange CVE assigned to OpenWrt? Aug 16 19:02:17 backdoor *coughcoughcough* side channel speculative execution style vulnerability Aug 16 19:09:14 https://www.cvedetails.com/cve/CVE-2018-11116 ? Aug 16 19:19:17 ntd: yes Aug 16 19:34:20 blogic: how is the cleanup going? Aug 16 21:58:39 blogic: suggest https for https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=blobdiff;f=package/firmware/ath10k-firmware/Makefile;h=b06861f3ff9de473b5dc4170b75e164b9b25691d;hp=f6a89311e34b8536c8f4c4b05c257fd33e0b4bfd;hb=bc57bafd6fb2e621d444e86f5369a615a0479a78;hpb=d42e1b6bfe40561541f4018e7afcf75bedcb3438 Aug 16 22:00:58 oh wait this looks like it can be rolled into the linux-firmware package Aug 16 22:11:16 Hauke: jow replied to a forum topic, the cve is user error, and not a cve at all. Aug 16 22:13:22 Hauke: https://forum.openwrt.org/t/rpcd-vulnerability-reported-on-vultdb/16497/4 Aug 16 22:39:16 could someone please take a look at the (unfortunately now-closed) PR https://github.com/openwrt/openwrt/pull/1237#issuecomment-412311019 and give a sanity-check on the suggestion to rename the routerstation target (from rs/rspro on ar71xx to routerstation/routerstationpro) for ath79? Aug 16 22:39:33 i'm still open to renaming it, it really just does not seem correct to me for the reasons i stated and i haven't seen a rational argument for doing so. **** ENDING LOGGING AT Fri Aug 17 03:00:04 2018